Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[phoenix91]

I ripped a CD (drive l:, internal) into file-type .ape. Every song had quality of 100% exept the third which needed re-reads (between 2-12) at 7 positions resulting in a quality of 89.44%. Ther were no unreliable reads.

I then re-ripped song no. 3 only in drive r: (external, USB connected), resulting in a quality of 100%.

So far so good.

I wonder now why the file-sizes of the two ripped songs no. 3 are not identical?
1. 83717 KB
2. 83944 KB

Repeated lossless, secure rips should produce identical files, shouldn't they?

U.

Media Center Registered 11.1.194 -- d:\Media\J River\Media Center 11\

Microsoft Windows XP  Workstation 5.1 Service Pack 2 (Build 2600)
Intel Pentium 4 1696 MHz MMX / Memory: Total - 785 MB, Free - 219 MB

Internet Explorer: 6.0.2900.2180 / ComCtl32.dll: 5.82.2900 / Shlwapi.dll: 6.0.2900 / Shell32.dll: 6.0.2900 / wnaspi32.dll: 4.71 (0002) , ASPI for Win32 (95/NT) DLL, Copyright © 1989-2002 Adaptec, Inc. / Aspi32.sys: 4.71 (0002)

Ripping /   Drive F:   Mode:Normal  Type:Auto  Speed:Max
  Drive G:   Mode:Normal  Type:Auto  Speed:Max
  Drive H:   Mode:Normal  Type:Auto  Speed:Max
  Drive I:   Mode:Normal  Type:Auto  Speed:Max
  Drive L: _NEC    DV-5800A          Mode:ModeSecure  Type:Auto  Speed:Max
  Drive R: HL-DT-STDVDRRW GSA-2166D  Mode:ModeSecure  Type:Auto  Speed:Max
  Digital playback: Yes /  Use YADB: Yes /  Get cover art: No /  Calc replay gain: Yes /  Copy volume: 32767
  Eject after ripping: Yes /  Play sound after ripping: No 

Burning /  Drive F: LG       CD-RW CED-8120B    Addr: 2:1:0  Speed:12  MaxSpeed:12  BurnProof:No
  Drive R: HL-DT-ST DVDRRW GSA-2166D   Addr: 4:0:0  Speed:48  MaxSpeed:48  BurnProof:Yes
  Test mode: No /  Eject after writing: Yes /  Direct decoding: No /  Write CD-Text: Yes
  Use playback settings: No /

[benn600]

You were a bit unclear.  Did you get unreliable or re-read errors one time?  I think they would only be identical as long as both got 100%.

[hit_ny]

Am a bit lost as well as to why the filesizes were not identical.

The % in the log only means more reads were reqd, not that it did not rip correctly, for that all that's needed is an OK.

Presuming you did get OK on the re-rip, i'd imagine the same file got ripped again.

What about the wav files ? instead of the ape. Are they identical or not.

[benn600]

If it didn't read it at 100%, then it didn't get the correct file.  That's just like a zip file...if it didn't get some bits correct, the size would be different and the file would be corrupted.

[hit_ny]

Umm, no, a similar question was answered here

"Completed OK" is enough. 100% is not needed for ripping the audio data correctly.

You may want to replace the CD for other reasons, but once MC has ripped it succesfully the files on a HD should be fine.

I know it's sounds confusing. When MC says "Complete - OK", it means what it says. It got all the data.

The percentage figure has nothing to do with the quality of the rip, only how many times it took to re-read the CD to get a complete - OK rip.

If you're getting pops and other noise, it's either in the recorded CD or elsewhere in the system.

I just want to reiterate that this is correct.  If MC says "Completed OK", you can sleep sound at night.  It'll tell you if it couldn't get reliable data.

[Alex B]

phoenix91,

Are you sure that you used the same compression level and the file tags are identical? Are the files on the same HD partition?

Convert the files to uncompressed wave and place the wave files side by side. Are they still different size?

Also, you can use Right-click > Properties in Windows Explorer for checking the real "Size" in bytes. (Not the "Size on disk".)

EDIT

If the files really contain different PCM audio data I wonder if MC is not capable of disabling your USB drive's cache (it can do that with standard internal drives). You got a 100% result so perhaps MC compared the cached data.

[benn600]

Interesting.  I seem to remember proving that wrong without a doubt on my own system.  I have had a few CDs which had some damaged areas (scratches).  Upon ripping, I got some errors.  I listened to the part where it said it had trouble and what a surprise, I found bad pops and sounds that were not in the original CD.  Repeated rips produced the same result.  After cleaning the disc more and possibly buffing it out, I got 100% and what a surprise, the sounds disappeared!  Therefore, I only accept 100% reads because I am assuming that the re-read thing means that the drive couldn't get it on its own re-reads.  I am thinking that drives inherently re-read on their own to get data but if the drive can't do it on its own, MC artificially forces the drive to read it over and over, but it doesn't check for consistency as well as the drive would and the data is then not 100% correct as it would be if the drive, only allowing 100% perfect data, was able to re-read without telling the computer.  It's an independent unit that retries for the data on its own.

I cannot verify this info at the time because it's been a long time.  I'll test it next time I run into a less than 100% disc and when I have more time.

[benn600]

'nother question: how does MC know if it got good data?  Does it run CRC checks on the data?  If so, can someone explain these checks a little bit?  It seems interesting that the computer knows if binary code is correct even though there are so many combinations of 1's and 0's that are correct...?

[Listener]

I ripped a CD (drive l:, internal) into file-type .ape. Every song had quality of 100% exept the third which needed re-reads (between 2-12) at 7 positions resulting in a quality of 89.44%. Ther were no unreliable reads.

I then re-ripped song no. 3 only in drive r: (external, USB connected), resulting in a quality of 100%.

So far so good.

I wonder now why the file-sizes of the two ripped songs no. 3 are not identical?
1. 83717 KB
2. 83944 KB

Repeated lossless, secure rips should produce identical files, shouldn't they?

A suggestion: the two drives may have different read offsets.  That might result in different amounts of data missing at the very beginning of the track.  Those bytes are usually silence so there is no loss of actual music.

EAC has an option "Fill up missing offset samples with silence".  I don't know what MC 11 does about missing offset samples.

Bill

[Alex B]

A suggestion: the two drives may have different read offsets. That might result in different amounts of data missing at the very beginning of the track. Those bytes are usually silence so there is no loss of actual music.

That came into my mind too. Often this tiny offset error passage contains silence as you said, but in some cases it can contain audio. That would make the audio data a bit different.

I wanted to know if the decompressed wave files have different sizes before trying the make further suggestions.

EDIT

However, because wave files are uncompressed the file sizes can tell only if the file durations are identical or different. The next step would be to use bit compare tool that compares the actual audio data.

[Listener]

I think that the offset is a characteristic of a drive rather than a ripper.  Whatever data was in the missing offset samples, you aren't going to get it with that drive. 

You might check the database of CD-R/DVD drives at

http://www.daefeatures.co.uk/search.php

to find out the offsets of your two drives.

Bill

[Alex B]

Each drive model has a certain read offset that is constant in all drives that are the same model or at least use the same firmware version (I am not sure if a firmware version can change the offset, probably not). Offset differences make files to start and end at slightly different points. Since one sample is 1/44100 s and a typical read offset can be anything between -2000 to + 2000 samples the differences are small and normally inaudible.

[phoenix91]

Thank you very much to everybody who posted and lead me on a way to understand my confusing ripping-problem. Sorry, it took so long for my answer, but I had to be away from home for a day unexpectedly.

Some checks I've made on the two .ape files:

• The files are on the same disk and in the same directory
• The file-sizes (right-click, properties) are different by 231'927 Bytes
• The compression level of both files is Monkey's Audio (APE)/normal. At least I think so, because I didn't change anything between the two rip procedures. In tag info I see Compression=Normal (3.99)
• The duration for both files is 13:43
• The bitrate is different 833 bps for the first file, 835 bps for the second
• BPM values are totally different 133/65 ?
• While listening to the two tracks, I don't notice any unexpected pops or hickups. But my ears are not this educated or especially sensitive. The CD is live-recorded and so there are many different sounds not only from the artists. BTW it's Dire Straits - Alchemy - Part Two, 03 - Telegraph Road.

As Alex and hit_ny suggested, i converted the .ape files to .wav. The result are two files with exactly the same size 145'177'244 Bytes.

Listener pointed to the technical value "read offset" of the two used dvd-drives. While I could find the value in the database for my external LG drive (+667), my internal drive NEC DV-5800A seems to old and is not mentioned. But, NEC drives seem to be in another range with their offset values.

Now, what can I do to get back my confidence in secure ripping on my PC.
A bit by bit comparison of the .wav files can be different due the read offset values despite identical sound information, if I understand everything right.
Every help is appreciated.

U.

[benn600]

Isn't APE an adaptive compressor so it can get better compression based on previous and upcoming music?  Since it is not streamable, does this mean that parts of second 50 of music come from varoius areas in the file?  I can't quite understand how the files uncompressed to the same size, though, except for something in my question but it's too complicated for me.

[hit_ny]

Now, what can I do to get back my confidence in secure ripping on my PC.
A bit by bit comparison of the .wav files can be different due the read offset values despite identical sound information, if I understand everything right.

Do 2 rips of the same track using the same cd-player and then compare their sizes.

Another quick way to tell if both files are the same is to use a checksum (md5 or sfv) and compare it with the second.

[phoenix91]

Hi hit_ny

Did several rips of track03 (4 with every drive). First with the internal dvd-drive then with the external dvd-drive.
Compared bitrates, beats (BPM), sizes and md5-checksums.
- With internal drive generated files are coincident.
- With external drive generated files are coincident

But bitrate/BPM/size/md5-checksum differ between the two group of files.

Alex presumed that MC couldn't flush the cache of the external drive before re-reading. This is very possible and explains the 100% quality rip and the different file-size (but not the different BPM values). But I remember rips with re-reads in this drive too (maybe, could have been copy-protected cds).
Is there a way to test a drive with a defined-faulty cd or test the cache-flushing?

U.

[hit_ny]

If the two drives have different offsets, is not reasonable then to expect the files generated to be slightly different. I'm not sure if MC can accept an offset value but i think EAC can.

Why not try with that then and see whether you get the files to be identical between drives.

[phoenix91]

@hit_ny
I just installed EAC und follow your suggestion. First have to get the right offset values for my drives. I'll let you know when I did manage it.
Thank you.

U.

[GHammer]

An experiment with one track from a single CD, all tags removed.

MC 12, secure rip

Plextor-
md5 hash = 5e45d5aa31c4d03c9019cf259bdd7
9170448 samples @ 44100Hz
File size: 26 488 844 bytes
 ----------

Pioneer-
md5 hash = 2980c957d21a607587b9c1f269b55ac
9170448 samples @ 44100Hz
File size: 26 488 728 bytes
 ----------

EAC secure rip

Plextor-
md5 hash = 1b29bc8e6491f8f57557334fd95ba2
9170448 samples @ 44100Hz
File size: 26 488 888 bytes
 ----------

Pioneer-
md5 hash = 31c558cc865458d8aa862a5a5d567953
9170448 samples @ 44100Hz
File size: 26 488 772 bytes
 ----------

I note no huge differences between drives or apps, so I'd say MC does a good job of determining the offset. Or EAC does a bad job of following its settings..

No matter which, the bitrate is identical.
Since the samples are the same, I'd expect the uncompressed WAVs to match.

[Alex B]

The OP used a live recording so perhaps it does not have silent gaps between the tracks. The offset difference between the two drives would naturally cause the Monkey's Audio files to be different.

If the start and end points contain digital silence on both drives it should not matter if one file has bit more silence in the start and the other one in the end. Monkey's Audio should compress the silent samples similarly, only the placement of these samples would be different.
EDIT: This does not mean that the resulting Monkey's Audio files would be identical, only that the actual audio content between the silent start and end points should be the same.

Wave files should always have identical sizes (not content) because an offset difference does not change the total duration. A silent sample in a wave file occupies as much space as any other sample.

[phoenix91]

I did further tests with EAC but was not able to get identical wav files with both drives.
EAC does not recognise a read-cache in my external dvd-drive. But nonetheless, maybe there is one. That would explain a lot. I couldn't find more information about that drive.
It's a LG GSA-2166D (external). Maybe somebody knows more.

I expect the problem in my hardware, not in MC. What makes me confused is:
- I ripped (ape/normal) another cd with absolutely no re-reads in both drives and compared the file-pairs
- The file-sizes are slightly different, must be the read offset (like in GHammer's example)
- bitrates are identical
- BPM values deviate a little, not for every track, but in 6 of 10.
  Example track 08: drive1=80 / drive2=78

Is there an explanation for this?

U.

[Alex B]

For BPM issues you can find an explanation here:

http://yabb.jriver.com/interact/index.php?topic=33915.msg231568#msg231568




Also, check the edit in my previous post.

[hit_ny]

Interesting to see Hammer's checksums, even after taking the offsets into account, the checksums are not identical.

I wonder what then to make of Accurate Rip

[phoenix91]

And I thought that BPM is exact mathematic science    
Thank you Alex.

I've made a couple of rip-test with different PCs and learned that my internal DVD drive isn't as reliable as others are. It has unreliable reads where other drives show only some re-reads and re-reads wher others read perfect.
DVD drives aren't expensive anymore, so I'm going to replace it with a new one. Found a post by Listener which will help me with that.
http://yabb.jriver.com/interact/index.php?topic=35238.0

What bothers me more, is the fact that my external drive pretended to provide perfect ripped CDs. But did not due to a read-cache that can't be recognized by MC. I wasn't aware of that, and maybe others aren't too.
Am I right with the recommendation to do my ripping-job only with internal CD/DVD drives?