Not quite, Jan. Audiotracks are organized in logical 2352-byte frames (after EFM-demod and EC, giving us 75frames/sec for 2Ch-44.1/16 data), while Datatracks use only 2048 of these for the data, the remaining bytes are used for an additional level of error detection/correction. Thus, data is safer than audio but consumes more low-level data for the same amount of net data.janneman said:
WRT ripping, I use PlexTools that came with the CD-burner and get excellent results
- Klaus
EDIT: I see Andy addressed that already. Damn "write-only"-mentality I sometimes trap into....
EDIT2: Oh well, the WIKI. Never saw/used that here I have to admit...
KSTR said:
OK, clear. So, how do these programs like EAC work, then? I mean, how do they know there is an error in the bit stream, and how do they know how to fix it?
Jan Didden
Hi Jan,janneman said:
they can only fix errors to the level that is provided for in the rather simple CDDA error correction mechanism (which can compensate for some 250 low-level bit errors per second). But, and that's the difference between a rip and a standalone CDP playback, the ripper can try to re-read the CD several times, adjusting things like rotation speed, laser power level etc and use the best bits of these individual scans to get as much valid data as possible. With my plextools software ie I can precisly tell the program what to do when errors occur.
- Klaus
KSTR said:
My question was more geared to how the ripper knows there's an error. All it sees is the bitstream, no? Corrected (or not) by the built-in ec.
Jan Didden
janneman said:
Hi Jan,
There's 'redundant' data stored with the useful data. This redundant information is like a parity or CRC check for the particular block of useful information its resides with. A comparison between the two is enough to assert whether there is or isn't errors. There's not enough info within the redundant data to build up a complete error free copy in the event the useful data has completely degenerated but as KSTR points out the drive and software can keep going over the data identified with errors and eventually extrapolate the correct data to fill in the errors.
janneman said:
The key is whether the CD/DVD is actually new. There are not too many problems imposed on a CD player error correction scheme with brand new CDs (audio or otherwise). However, what about old scratched up CDs? I would venture that most of us don't routinely install very old beatup installation CDs, so it's difficult to say how good the error correction really is.
ShinOBIWAN said:
Hi Ant,
I'm aware of the way red book CD players do Reed-Solomon interleaved error correction in hardware, in the player, using redundant data.
But here, are you suggesting that apps like EAC, that live in the PC and not on the drive, receive two data streams from the drive, one the data, the other the redundant data, and that it is up to the program to put humpty dumpty together again? Are you also suggesting that such an app can go in to the drive and adjust laser power?
Jan Didden
Bu
Hi Jan,
There's a pretty decent description of how EAC rips here. Some of what it does is dependent on the features of the drive (C2 error detection, etc.).
Since you have your SB Duet now, it's definitely worthwhile to check out some of this kind of info. Now that there's a thread dedicated to this, that will help all the more.
There's a pretty decent description of how EAC rips here. Some of what it does is dependent on the features of the drive (C2 error detection, etc.).
Since you have your SB Duet now, it's definitely worthwhile to check out some of this kind of info. Now that there's a thread dedicated to this, that will help all the more.
janneman said:
Exactly that Jan.
Error checking and correction is used extensively throughout data storage.
It might be worth taking a quick glance at how RAID 5 operates because the same very basic theory is at work with most digital storage. ECC RAM would be another example. They're all interrelated and share the same end result of avoiding and correcting errors or data loss but not the same operating specifics.
PMA said:
I don't get it???
Sorry to rattle a few cages. Some of the CD ripping sites have stuff that is as pure a nonsense as any. Some even provide files to flash the firmware on your drive or players, and failure of that can render them useless.
To be fair EAC has mostly way too much nerdy information which I assume is mostly technically correct. It's free so who cares, use it.
Don't tell me the same CD ripped with it and another program to the same hard drive and played off of the same hard drive sound "dramatically" different even though the bits are exactly the same by comparison. This has been told to me by at least two people.
janneman said:
Actually EAC used to read everything at least twice, and possibly multiple times, to be sure to get a current reading. This was because older drives did not report read errors on audio data. But newer drives do report read errors on audio data, so it is perfectly possible to rip an audio CD at 40X without any errors. If the drive detects errors, the application will then tell it to slow down and re-read the spot where the error occured, at much lower speeds, like 1X. This way it is possible to rip accurately and fast. A clean CD will take a few minutes, but a badly scratched CD will take forever.
EAC handles this. Since I have a Plextor burner, I use PlexTools, which also supports this feature. I believe some other programs do.
I have also had success is using disc polishers like DiscDoctor to rescue unreadable scratched CDs. In that case the rip will probably outlast the physical disc itself by a few decades (since I store them on RAID5 and I also have backups).
Anyway, the physical CD is dead. It is so damn obsolete. I'm waiting for the record companies to wake up and offer 24-196 FLAC downloads. This will not come from the majors, but Magnatune does it (actually 24-96 FLAC).
Scott,
I can't recall any talk of rips from differing software being audibly superior. As long as we get 1:1 rips with any errors corrected then I think everyone is happy and the software is doing its job.
I can't recall any talk of rips from differing software being audibly superior. As long as we get 1:1 rips with any errors corrected then I think everyone is happy and the software is doing its job.
h_a said:
That's fine with me, I wouldn't bet that I could tell the difference between a 192K mp3 and the 24/96 original of some LP's that I transfered anyway, though I will agree the LP'ness makes it into the mp3.
peufeu said:
Hear, hear!
Also Pavel linked to Linn Records earlier in this thread and they provide 24bit 96Khz recordings for most of their offerings.
My digital filters are double precision floating points at 192Khz so I'd dearly like to avoid having to use SRC hardware. 192Khz recording would solve this problem, I can but hope!.
Another one for the vinyl to CD thread
I tried this a while back; transfer a whole side of an LP to your hard drive , now without changing anything move the needle back and do it again. Using a pop or tick common to the leadin groove line the the left channel from one up with the right channel of the other in Audition or whatever and play the result. Quite a revelation, you might think your turntable is one sick puppy.
I tried this a while back; transfer a whole side of an LP to your hard drive , now without changing anything move the needle back and do it again. Using a pop or tick common to the leadin groove line the the left channel from one up with the right channel of the other in Audition or whatever and play the result. Quite a revelation, you might think your turntable is one sick puppy.
scott wurcer said:
It is Julian Dunn jtest, 11025Hz -6dB sine + toggle LSB 229Hz. When I tried to rip it back from properly burnt CDs, I got different wav files. Audiograbber changed ratio between amplitude of sine and toggle, made toggle bit with higher amplitude. Also, problems with burning to CD, "skirt" around base frequency. Properly ripped by foobar and properly burnt by Nero.
The spectrum of the ripped wav should look like this:
Attachments
- Status
- Not open for further replies.