Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: iTunesEncode + EAC (Read 5038 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

iTunesEncode + EAC

Using Otto's excellent tool I started converting my CD collection to Apple Lossless for permanent archival and peace of mind. Imagine my horror therefore when a certain track, when played back from the Apple Lossless file, exhibited a very large crackle. I checked the track on the CD: no crackle. I reripped the track fine, but this does leave a vital question hanging around: can the method be trusted? What about the hundreds of tracks already ripped? And why did the crackle occur? I thought the method would be error free......

iTunesEncode + EAC

Reply #1 –
iTunes is known to have certain issues with playback on some setups. Might want to figure out if the "crackle" is in the file itself, or in iTunes playing the file.

iTunesEncode does not modify the wav between EAC and telling iTunes to encode it.

iTunesEncode + EAC

Reply #2 –
Unfortunately, I deleted the file. But before I did, I checked it out on another m4a player: foobar2000. It exhibited the crackle on that too. So I fugred it was in the file itself.

iTunesEncode + EAC

Reply #3 –
Surely this is a serious issue? If a file has a pop/crackle in it when the source does not, does this not throw doubt upon the entire EAC/iTunesEncode process? What could possibly have caused the sound file to be non-perfect?

iTunesEncode + EAC

Reply #4 –
It really depends how often it happens.  If it happens 1:1000 times to 1:1000 people then I don't think most people will think it's a big deal.  I myself am concerned about it because I was just going to start encoding my enitre (400+ CD) collection using iTunes 5 with the new VBR option.  I was planning to use EAC along with iTunesEncode, but this makes we wonder if I should wait or look for other methods.  Did you use EAC to test the drive you're using to read the CDs?  I found one of my drives does some internal buffering that does more bad than good when it comes to getting a perfect copy.

iTunesEncode + EAC

Reply #5 –
Quote
Surely this is a serious issue? If a file has a pop/crackle in it when the source does not, does this not throw doubt upon the entire EAC/iTunesEncode process? What could possibly have caused the sound file to be non-perfect?
[a href="index.php?act=findpost&pid=331852"][{POST_SNAPBACK}][/a]

iTunesEncode cannot possibly have any issues along these lines. It simply doesn't work that way. It doesn't touch the input file. It doesn't even open it for reading.

-If the fault is in the encoded file but not in the ripped WAV file, then iTunes' encoder is to blame.
-If the fault is in the WAV file produced by EAC, then EAC is to blame (and you likely have your ripping settings wrong somehow).

So find out where the fault originated, and then you've got something. Listening to the original WAV file from EAC would prove enlightening, I feel.

iTunesEncode + EAC

Reply #6 –
If I had the original wav file, I assure you I would have listened to it as well. Unfortunately, I had assumed that the m4a file would be a perfect backup therefore periodically deleted the huge numbers of wav files created by the eac/itunesencode process, the m4a's being my backup.

I do trust the itunesencode process: after all, it is a simple algorithm run on a file. However, could heavy load during an EAC ripping session be responsible for the distortion? I.e. if I were running CPU intensive processes while EAC was doing its extraction? I would have thought that since EAC checks every sector, that heavy CPU load would not affect the extraction, am I wrong on this?

iTunesEncode + EAC

Reply #7 –
Quote
I do trust the itunesencode process: after all, it is a simple algorithm run on a file. However, could heavy load during an EAC ripping session be responsible for the distortion? I.e. if I were running CPU intensive processes while EAC was doing its extraction? I would have thought that since EAC checks every sector, that heavy CPU load would not affect the extraction, am I wrong on this?
[a href="index.php?act=findpost&pid=332091"][{POST_SNAPBACK}][/a]

Unfortunately, that I can't tell you. I don't know anything useful about how EAC works, really. All I do know is that without the original WAV to compare against, there's no easy way to tell where the problem was introduced. You can try ripping/encoding under heavy load conditions (run Prime95 or something while ripping) and see if that makes any difference.

One thing is that if it's the encoder introducing the distortion, then it should theoretically be doing it with that same song on a consistent basis. Encoding is a deterministic process. So rip that song again from the CD, then see if the cracking is in the M4A again. If it's not, then it's quite likely that the ripper was at fault the first time, and that your EAC settings may not be 100% correct.

EAC can get a perfect rip in a secure manner, but things like caching will mess it up and such. Gotta have it set up just right.

iTunesEncode + EAC

Reply #8 –
Quote
Did you use EAC to test the drive you're using to read the CDs?  I found one of my drives does some internal buffering that does more bad than good when it comes to getting a perfect copy.
kneeslasher, 
You seem set on determining the root cause, but you haven't publically addressed my point (and it very well could be the culprit).
 

iTunesEncode + EAC

Reply #9 –
ItunesEncode is just a command-line interface that calls functions in the Itunes COM interface. As others have mentioned, ItunesEncode doesn't directly touch the files directly, it just passes your file to Itunes. I guess it is remotely possible (although unlikely) that the itunes COM interface has a bug in it though...