I used GRIP in Linux to convert my music CDs to FLAC. I didn't realize it at the time, but I have numerous CRC mismatches in the encoded files where physical scratches were located. Normally, I don't ever notice these errors during playback in Amarok or on my Squeezebox.

Since I recently bought an iPod, I had to convert all my FLAC files to MP3 using flac and lame on the command line. These mp3 files contain silent breaks anywhere there were CRC mismatches in the flac file. The same effect occurs when I use winamp to convert FLAC to mp3 in Windows. I know it's theoretically possible to interpolate through the errors, because we are oversampling with the FLAC format (~900 kbps vs. 320 kbps). But, how can I decode through errors while interpolating to get rid of silent breaks in my music??? This must be how Amarok and Slimserver deal with errors, so why is it not an option in the flac binaries?

-J

FLAC does not oversample. It merely doesn't throw anything away to reduce the bitrate, i.e. FLAC is lossless, MP3 is a transform codec.

Why not Rockbox your iPod to allow it to play FLAC?

Exactly right, but CD quality @ 44kHz is oversampling the audio band by design. Yes, you can argue that audio band is 20Hz to 20kHz and Fs=2.2x the highest frequency is minimal. Fact is, mp3s are decimated versions of the original signal and you shouldn't have to zero out any errors, just filter it to "guess" between the known samples.

Anywho, I have a new iPod video that I don't want to hack quite yet.

Uh, no it isn't.

Uh, no they aren't.

You may want to look up the terms oversampling and decimation because you are not using them correctly.

Where are you coming up with this nonsense?

If you're looking for a flame war, look elsewhere. I'm not interested.

I'm getting this "nonsense" from years of experience as a signal processing engineer. I'm sure in other areas these terms have parallel meanings. But here, in the signals sense I'm using them correctly. Why do you think mp3s are lossy? Because it resamples (and compresses) using either constant or variable bit rates that are DECIMATED and filtered versions of the original.

I'd still appreciate some suggestions for existing software that will avoid inserting zero padded samples in places having CRC mismatches.

Thanks,

J

Application of interpolation is not very interesting when the typical amount of data lost due to a single instance of corruption in a flac file is about a tenth of a second.

No offense, but as a signal processing engineer you should know that oversampling means: sampling at a higher sampling frequency than twice the highest frequency present in the signal. The sampling frequency used in CD's (44.1 kHz) has nothing to do with oversampling. It would be oversampling if the bandwidth was first reduced to 0-10 kHz, before sampling at 44.1 kHz, for example.

Also, the main concept of mp3 consists of storing the audio data with as least bits as possible, while keeping the quantization noise below hearing threshold and the masking threshold. This is not the same as decimation (quantization is the key word here). The amount of filtering and bandwidth reduction is only very minimal.

There's such a thing as decimation-in-frequency, but I think the guy really ought to revisit his copy of Oppenheim and Schafer.

I don't really understand how there can be CRC errors in the FLAC file because of scratches on the CD. This just doesn't seem possible, and the ripping software should have filled in unreadable sections with digital silence.

Anyway, I'd recommend re-ripping your CDs with EAC or dBPowerAmp, running natively under windows, to get the best possible rip. EAC will tell you if it finds any unreadable data, and tell you the exact position in the audio file.

Yes, but as far as I know this has nothing to do with data reduction, but with efficient calculation of Fourier Transformations. Am I right?

Ontopic: you would say that if software can play the FLAC files correctly (at least this is what I understand from your post), than CRC errors should not stand in the way of converting the files to mp3's without silences... Have you tried using foobar (under Wine) to convert the files?

Unfortunately, re-ripping would be very time consuming since I have about 200+ CDs already copied over. That may be the only option though.

GRip usually does a nice job at ripping. Some CDs that I was trying to salvage had pretty extensive damage to the outer sectors from careless handling. When GRip came to those sectors, it took many many cycles to attempt to read them. I was making an assumption that the CRC errors were caused by data corruption during ripping. If that's not possible then maybe my hard drive was failing earlier than I thought. The files were regularly backed up, but I needed to replace the primary drive at one point after ripping. I can't see any other ways the data would become corrupted after ripping.

No, I haven't tried using foobar to convert. I suspect it's the FLAC binary decoder. When I try it out, I'll let you know the results.

Off-topic: I agree that original CD quality sound is not an oversampled signal. I was referring to the audible sound that you will hear when it is played back. Mp3 encoding exploits human hearing thresholds among other tricks and so I was only referring to the fact that mp3s contain modified spectral content. Reviewing mp3-tech.org, I concede that this is not decimation in the traditional sense. That would be a gross simplification.

Would be? You mean it was a gross simplification:

So are these ripping errors from Red Book Audio CDs or are they errors from flac files that have gotten corrupted?

If it's a ripping problem and you're able to use foobar2000, may I suggest you also use a ripping program that is native to Windows such as EAC or dBpowerAMP? Like most Linux solutions, Grip doesn't look terribly promising as a secure ripper.

It could be either at this point. I don't know enough about the FLAC format to say what the problem really is. I do know that certain problem CDs seem to have CRC mismatches more than the clean CDs. I'll have to experiment with a clean and dirty CD to see if I can replicate the problem.

Doubtful, but you can always use flac -t on the ones you think are bad to be sure.

Anyway, re-ripping 200+ CDs isn't gonna kill ya.

Use bust T&C, a rip/re-rip mode with a non-caching drive, or a C2 T&C rip if it's any faster.

If you have a caching drive:
I suggest you only use a secure mode with tracks where a burst T&C rip can't deliver matching CRCs, and make sure to only use a program that was designed to make sure re-reads always cause the drive to seek new data from the disc and that steps were taken to reduce the likelihood of consistent errors over a variety of drives.

Without the help from an external database, your best bet is to use a ripper that makes use of C2 pointers to eliminate bad data during re-reads in conjunction with a drive that can provide them.

Finally, if your drive doesn't perform interpolation to your satisfaction, you may consider trying a different one or try software that can also provide this feature. Of course it isn't all that difficult to damage a disc beyond the point where errors can be concealed.