Bit-perfect CD ripping
Jan 26, 2011 at 9:13 PM Post #31 of 58
 
What exactly is your issue? Are you ripping an original cd or a burnt copy? If you are ripping from a copy and that copy was not ripped accurately and then burnt accurately including the cue sheet and drive offsets you will not be able to achieve a bit perfect rip. If you are ripping an original and you would like to recreate bit perfect copies will will also need the drive offsets set up properly and the cue sheet, currently this is where eac has the advantage as dbpa does not create cues. Personally I use dbpa and have never had any issues recreating as long as everything is setup correctly and you have the cue file.
 
Jan 27, 2011 at 8:14 AM Post #33 of 58


Quote:
What about on a Mac? I have a number of programs (iTunes, XLD, and Max) and I generally end up using iTunes and ripping to ALAC. Is this a bad idea?

IMO yes it is a bad idea. basically using EAC to rip to flac is better than using itunes to rip to alac and these are my reasons:
 
1) ALAC ripped through itunes is not bit perfect. It uses an inferior form of error correction and will guess at bits if it encounters errors.
2) you are stuck with a proprietary codec.
 
The best solution is a bit perfect rip with proper error correction(EAC) to a lossless compression non-proprietary codec (FLAC) that can easily be converted back to the original form (wav). Then you have a perfect digital copy that is future proof.
 
Jan 27, 2011 at 8:27 AM Post #34 of 58
For perfectly Burn your ripped CD from EAC, you have to setup the burner's offset too.
And preferably, you can use EAC's burning tool which can utilize cue sheet.
For just ripping the bit-perfect wav, you only need read offset.
 
It seems like you didn't setup write offset,
 
Quote:
I just attempted to test the accuracy of EAC (set up according to xunside's guide) by burning a CD (containing one song) with Burrrn!, ripping it to my computer with EAC and comparing the resulting file with the source file using the Foobar Binary Comparator plugin.
 
The resulting log:
 
Differences found: 18345978 sample(s), starting at 0.0000000 second(s), peak: 1.9678955 at 107.1002494 second(s), 2ch
 
More than 18 million samples, starting at index 0. That has to be the entire song. It's like EAC added dither or something.
 
I tried ripping twice and the results were the same as far as I can remember, although the second time the ripping seemed to go faster as well as with less error correction.
 
This is just ridiculous. EAC is supposed to be a secure ripper. I can understand if the length of the songs aren't identical, but surely the actual content ...
confused.gif

 
 
Back at Hydrogenaudio they didn't respond to this question with too much friendliness, for some reason. Please help me. I just want to understand.
triportsad.gif

 
EDIT: Also, explorer displays the files as being exactly the same SIZE.



 
Jan 27, 2011 at 8:55 AM Post #36 of 58
Actually, ALAC is bit perfect (though lossless codec is a better term here). But using iTunes is still not a great idea, as it doesn't use as robust a rip method as EAC or dbpa.
 
Quote:
1) ALAC is not bit perfect.



 
Jan 27, 2011 at 9:14 AM Post #37 of 58


Quote:
Actually, ALAC is bit perfect (though lossless codec is a better term here). But using iTunes is still not a great idea, as it doesn't use as robust a rip method as EAC or dbpa.
 
Quote:
1) ALAC is not bit perfect.


 

no. If I meant lossless I would have said lossless. I meant bit perfect. It will not provide a bit perfect copy of a wav file from a CD.
 
 
Jan 27, 2011 at 11:35 AM Post #38 of 58
But accepting that ALAC is lossless, then saying it is not bit perfect, is nonsensical. The codec doesn't care what data it is passed from the ripping software, which is what determines whether something is bit perfect or not.
 
For example, you could use EAC to ALAC and you would have a bit perfect copy with lossless compression. iTunes is the problem, not ALAC.
 
Quote:
no. If I meant lossless I would have said lossless. I meant bit perfect. It will not provide a bit perfect copy of a wav file from a CD.
 



 
Jan 27, 2011 at 11:52 AM Post #39 of 58
To put it in a practical term, for a lossless codec if you let a PCM wave data (X) go through the codec you should get the encoded file in this lossless codec format (C). Vice versa when you put that encoded file (C) through the codec again you should get the X wave data back. IOW lossless means bit by bit equality (or bit perfect if you prefer) supposedly the encoding and decoding processes are correct. If in some cases, the result you get is not bit perfect it's the fault of the decoding or encoding software, not the lossless codec format itself. Because if the "lossless" codec format is not bit perfect, it is simply not a lossless format.
 
Jan 27, 2011 at 11:56 AM Post #40 of 58


Quote:
But accepting that ALAC is lossless, then saying it is not bit perfect, is nonsensical. The codec doesn't care what data it is passed from the ripping software, which is what determines whether something is bit perfect or not.
 
For example, you could use EAC to ALAC and you would have a bit perfect copy with lossless compression. iTunes is the problem, not ALAC.
 
Quote:
no. If I meant lossless I would have said lossless. I meant bit perfect. It will not provide a bit perfect copy of a wav file from a CD.
 


 


ok I am sorry. we are on the same page, but having a slight miscommunication. ALAC itself is bit perfect. Creating alac through itunes, like the user in question is doing,  is not. I should have been more clear.
 
Jan 27, 2011 at 1:23 PM Post #41 of 58
So you're saying iTunes massages the data in some way before passing it to the encoder?  If that's the case, WAV wouldn't be bit perfect when ripped with iTunes.  Your comments are the first I've seen that make this claim.  Everything else I've read says you can convert an ALAC file back to a bit perfect WAV.  I've not tried it my self so I don't know. 
 
I don't use iTunes to rip for other reasons, the fact that it doesn't use accurate rip, supposedly not as good error correction, and the fact that it only uses 1 database for meta data lookup.  The last one is why I chose dbPowerAmp over EAC.  I do rip to ALAC with dbPowerAmp, which uses Nero.
 
Jan 27, 2011 at 1:35 PM Post #42 of 58


Quote:
So you're saying iTunes massages the data in some way before passing it to the encoder?  If that's the case, WAV wouldn't be bit perfect when ripped with iTunes.  Your comments are the first I've seen that make this claim.  Everything else I've read says you can convert an ALAC file back to a bit perfect WAV.  I've not tried it my self so I don't know. 
 
I don't use iTunes to rip for other reasons, the fact that it doesn't use accurate rip, supposedly not as good error correction, and the fact that it only uses 1 database for meta data lookup.  The last one is why I chose dbPowerAmp over EAC.  I do rip to ALAC with dbPowerAmp, which uses Nero.



Itunes doesn't massage the data. I never said that. You nailed the reason not to use itunes right in your response. it doesn't use proper error correction, and can result in an imperfect copy of a file from a cd.
 

Users who are viewing this thread

Back
Top