Posted: Sun Oct 03, 2004 10:32 pm
Not to get too far off topic, but I have wondered about something relating to (I guess it is) the PQ subcode. I have 4 "copy controlled" Kevin Ayers CDs, which use CDS 300. I was able to extract all of the audio info intact (no clicks!) using Missing Media Media Burner, but the time info was incorrect. When I'd place the individual files into Bias Peak, the program would return an error, saying it couldn't locate the end of the file. It was a minor error, as the sound file would still come up and would play fine. Further poking around with this led me to discover that the time of the track was off by just a few frames. That is, I discovered, one of the tricks used by Cactus Data Shield for "copy protection".
Now, copying and saving the ripped file as another aiff or wave or whatever always resulted in an incorrect time duration. Trying to convert to lossy mp3 in LAME yielded the same incorrect result. But when I converted the aiff file to FLAC and/or Apple Lossless the problem was gone! The time was now correctly reported. Converting those lossless files back to aiff also preserved the correct times. Problem solved at last! Strange, isn't it?
My theory, then, is this: even though the PQ subcode info is not carried over when exporting an individual track, it appears that the ripper initially obtains the time info from the PQ subcode and treats it as gospel, whether it is actually correct or not. I can only conclude that protection schemes like Cactus Data Shield are taking advantage of this flaw in CD rippers. (Certainly Toast and cdda2wav have this flaw. Perhaps EAC is more "intelligent" in this regard? I've never used it, so I don't know. I've asked at Hydrogen Audio, searched all over the net, and have never found an answer to any of this. BTW, what I'm describing isn't simply a by-product of one CD-ROM drive either; I've ripped these discs in an external Plextor, an external Yamaha, and an internal DVD-ROM drive -- same thing happens. Obviously, CDS "protection" fools with the time subcode in order to confuse ROM drives.)
What I can't really answer is why converting, say, an aiff to a wave file still preserves the incorrect time info, but going from aiff to FLAC or Apple Lossless results in a correct time. My guess is that these lossless codecs -- or at least the programs running them -- are designed to be more "intelligent", ignoring the given time duration, and will instead count the actual frames in the sound file.
Something to keep in mind if you ever encounter a problem like this. You may be able to play sound files with incorrect times on a computer without noticing any ill effects, but these incorrect times will cause havoc if you attempt to burn them to CD or convert the files to another format.
It took me five nights of increasingly mounting frustration and bewilderment to figure all of this out! So I thought I'd pass on my hard won discoveries to whoever may find it of any use.
Now, copying and saving the ripped file as another aiff or wave or whatever always resulted in an incorrect time duration. Trying to convert to lossy mp3 in LAME yielded the same incorrect result. But when I converted the aiff file to FLAC and/or Apple Lossless the problem was gone! The time was now correctly reported. Converting those lossless files back to aiff also preserved the correct times. Problem solved at last! Strange, isn't it?
My theory, then, is this: even though the PQ subcode info is not carried over when exporting an individual track, it appears that the ripper initially obtains the time info from the PQ subcode and treats it as gospel, whether it is actually correct or not. I can only conclude that protection schemes like Cactus Data Shield are taking advantage of this flaw in CD rippers. (Certainly Toast and cdda2wav have this flaw. Perhaps EAC is more "intelligent" in this regard? I've never used it, so I don't know. I've asked at Hydrogen Audio, searched all over the net, and have never found an answer to any of this. BTW, what I'm describing isn't simply a by-product of one CD-ROM drive either; I've ripped these discs in an external Plextor, an external Yamaha, and an internal DVD-ROM drive -- same thing happens. Obviously, CDS "protection" fools with the time subcode in order to confuse ROM drives.)
What I can't really answer is why converting, say, an aiff to a wave file still preserves the incorrect time info, but going from aiff to FLAC or Apple Lossless results in a correct time. My guess is that these lossless codecs -- or at least the programs running them -- are designed to be more "intelligent", ignoring the given time duration, and will instead count the actual frames in the sound file.
Something to keep in mind if you ever encounter a problem like this. You may be able to play sound files with incorrect times on a computer without noticing any ill effects, but these incorrect times will cause havoc if you attempt to burn them to CD or convert the files to another format.
It took me five nights of increasingly mounting frustration and bewilderment to figure all of this out! So I thought I'd pass on my hard won discoveries to whoever may find it of any use.