User:Mjb/CD ripping

From Offset
Jump to navigationJump to search

Exact Audio Copy

Timing problem

An EAC burst rip will say "Timing problem" if a read command took an unusually long time, possibly because the drive was losing sync or was trying to fix a read error. The data may be fine. This is in the FAQ.

Pre-emphasis

Pre-emphasis flags are only read from the TOC, where they are quite often going to say "No" when the subcode correctly says "Yes". There were a few EAC "0.95 prebeta" versions which could read the flags from subcode as part of "manual TOC detection", but this feature was removed because it could somehow also be used to circumvent copy protection.

CUERipper

Copy OK

The EAC-style log says "Copy OK" on all tracks, regardless of what happened during the rip. Discussion: http://www.hydrogenaud.io/forums/index.php?showtopic=104498

Pre-emphasis

On the CD The Digital Domain, the first 17 tracks have pre-emphasis, as do tracks 22 and 24. I confirmed that the disc has correct subcode flags set by checking the analog output for these tracks in a real CD player; they play with the proper attenuation. However, CUERipper adds FLAGS PRE in the cue sheet for tracks 21 and 23 as well. So it seems CUERipper can make mistakes when reading these flags.

cdda2wav

Another way to read subcode flags is with cdda2wav, a command-line tool in the cdrtools package. To just get the disc info without ripping, the command line is like this (though the device ID may vary):

Run it without arguments first to get your device ID list. Then plug in the ID (e.g. 4,0,0) like this:

  • cdda2wav dev=4,0,0 -J

It will scan the disc and output a set of INF files, which are text files of name-value pairs. Load one in a text editor and see

Pre-emphasis

For the CD The Digital Domain (see above), cdda2wav reports pre-emphasis on tracks 1 through 16 (not 17), and on 21 & 23 (not 22 & 24). It seems to also maybe say that there are moments when the subcode and TOC disagree within those same tracks. So it seems cdda2wav is not 100% reliable for this info either.

S/PDIF capture

My real CD player has a digital S/PDIF output. This is probably 20-bit, 44.1 kHz output, with the bottom 4 bits of each word set to zeros (since the CD only has 16-bit data).

Unfortunately, I have to use an old AudioAdvantage Roadie USB soundcard to capture it, and it is a piece of junk. I have trouble getting a setup that doesn't add noise, resampling artifacts, or HF rolloff.

I got a slight level boost and added broadband noise when I captured through the MME interface. So instead, after much trial and error, I got it to work if I use:

  • in Windows, set recording device to the Roadie SPDIF input, and under advanced set it to 16-bit, 44100 Hz.
  • in ASIO4ALL, have only the Roadie's input enabled (no outputs), the advanced options set so all the checkboxes are off.
  • select ASIO4ALL and 44100 Hz from the hardware prefs in Audition.
  • record at 32-bit 44100 Hz in Audition. Zoom in and make sure when nothing is playing it is truly digital silence. Don't start the recording at 16 or 24 bit because there is a bug (or feature) where no matter what the dither settings are, you get triangular dither in the output when saving (you won't see it till reloading the file). The only way to avoid it is to open at 32 and then save at the desired bit depth.

Naturally, I have to trim the ends and make sure it's aligned if I want to compare this to a DAE rip.

Check alignment

If the S/PDIF capture produced an identical waveform, but is not bit-identical due to an offset of roughly half a sample, then resampling occurred somewhere. Check settings and try again. You should be able to get the same results as a DAE rip.

Pre-emphasis

Pre-emphasis is not applied when I do S/PDIF capture. The data stream does include a pre-emphasis flag, but if it is being set, it is being ignored by the soundcard. This may be by design, as it is just trying to pass the data through.