CUERipper - .cue sheet generation

Hi,

Simple question ...

Is it possible -- with CUERipper -- to generate a .cue sheet for an album image, from a CD, without actually ripping that CD?

In particular, I want a quick-and-dirty single function to detect pre-emphasis. I plan to continue to rip my CDs using another software program.

Thanks!

 

EAC/dBPoweramp, pop the disc in and it will detect right then and there, no scan required for table of contents flag.
Problem lies within detecting SUBQ flags. Besides the right software, not all drives will detect it.

 

My understanding is that EAC will *not* detect subcode flags, so that's not an option. I've determined that CUERipper is a reliable detector (and it writes the PRE as a value for the FLAGS keyword in the .cue sheet). I'm simply not using dbPoweramp ... hence my specific question about CUERipper.

 

An old pre-beta of EAC will for SUBQ.
Did you try CUETools?
Years ago I think I was able to perform a SUBQ scan without ripping.

 

I just loaded up CUETools/Ripper, no go, unless i'm really missing something for just a cue sheet/confirmation.
eac095pb3 quick and easy for subq flag detection. Scan only took a couple minutes.
Pink Floyd-Dark Side.

 

Thanks c-eling ... I know there are other options, but I was really looking for a CUERipper option for this.

One thing I've noticed ... CueRipper writes the .cue sheet immediately when the extraction starts. I can "ABORT" the rip and the .cue file is preserved. And this is obviously "fast." I'm just looking for something more elegant.

 

I played around with CUERipper and didn't see a way to get it to create a CUE sheet without starting a full rip.

I also checked the list of command line options for CUETools and CUERipper to see if there might be a command line option to generate a CUE sheet. There isn't. Bummer.

CUERipper and CUETools are open source (source available on github). If you know some C# and have Visual Studio (the free version should work for this) you could modify CUETools to have a button that says "make CUE sheet" and have it do just that. Not a good option unless you're a software developer.

 

More generally: Is it possible to reliably determine if pre-emphasis exists without ripping the audio? A: No.

A pre-emphasis flag for each track is normally stored in the subcode along with the audio data. It's also supposed to be stored in the table of contents (TOC), but many CDs have TOCs that say there's no pre-emphasis when in fact the subcode says there is. There are also some CDs which people believe were mastered with pre-emphasis, but which have no pre-emphasis flags set at all.

 

How much of the CD would you need to rip to find out if there is pre-emphasis in the subcode? Would you just need to rip a single frame? You aren't going to need to rip the entire CD or even an entire track.

 

It should be discoverable pretty early in ripping segments of the disc audio, unless you have a disc producer so clever and subversive to alternate tracks with and without pre-emphasis and correctly master them, which is conceivable situation if a disc compiler received different digital encodings.

Since the number of worldwide preemphasis discs can be counted on two hands (in binary), this is quite unlikely, but still not impossible. Here is one CD where per-track pre-emphasis is used and signaled.

A tool could be written to do such track analysis as efficiently as possible, but CUERipper is not among them.

 

Have you used CUERipper?

I looked at your referenced hydrogen audio post, and this is one of the things it says:

Moreover, CUERipper writes the cue sheet (which reports the use of pre-emphasis, track-by-track) within seconds of commencing the rip.

So ... I would assert that whatever algorithm CUERipper uses to "read" the subcode, to search for pre-emphasis flags, is -- indeed -- very efficient.

Unfortunately, as we're learning in this thread, the CUERipper interface doesn't enable a function that permits one to write the .cue file without extracting all of the audio data (a lengthy process). As @Ham Sandwich writes, above, the open-source nature of CueRipper would enable someone with initiative to "fix" that particular issue, but it's nothing I care to dive into (and I make my living as a software developer).

To summarize:

1. As evidenced by my experience and the referenced hydrogen audio post, CUERipper is wonderfully capable of correctly extracting pre-emphasis flags from subcode on a track-by-track basis.
2. The algorithm it employs is very efficient (a few seconds, or less, per CD).
3. Out-of-the-box, the algorithm is implemented only as part of the function that rips the entire CD, a lengthier process that could be circumvented by re-architecting the code.

 

If it happens nearly instantaneously, it is from solely reading the disc's table-of-contents, not the subcode that accompanies audio.

Here, I extract the TOC in seconds using CDRTFE (and then cut and paste the hard-to-read log window here)

C:\download\cdrtfe-1.5.8portable\tools\cdrtools\cdrecord dev=2,0,0 -toc -v
cdrecord: Insufficient 'file read' privileges. You will not be able to open all needed devices.
cdrecord: Insufficient 'file write' privileges. You will not be able to open all needed devices.
cdrecord: Insufficient 'device' privileges. You may not be able to send all needed SCSI commands, this my cause various unexplainable problems.
cdrecord: Insufficient 'memlock' privileges. You may get buffer underruns.
cdrecord: Insufficient 'priocntl' privileges. You may get buffer underruns.
cdrecord: Insufficient 'network' privileges. You will not be able to do remote SCSI.
scsidev: '2,0,0'
scsibus: 2 target: 0 lun: 0
SCSI buffer size: 64512
cdrecord: Warning: Cannot read drive buffer.
cdrecord: Warning: The DMA speed test has been skipped.
Cdrecord-ProDVD-ProBD-Clone 3.02a09 (i686-pc-cygwin) Copyright (C) 1995-2016 Joerg Schilling
TOC Type: 1 = CD-ROM
Using libscg version 'schily-0.9'.
atapi: -1
Device type : Removable CD-ROM
Version : 0
Response Format: 2
Capabilities :
Vendor_info : 'Optiarc '
Identifikation : 'DVD+-RW AD-7270H'
Revision : '101A'
Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM.
Current: CD-ROM
Profile: DVD+R/DL
Profile: DVD+R
Profile: DVD+RW
Profile: DVD-R/DL layer jump recording
Profile: DVD-R/DL sequential recording
Profile: DVD-RW sequential recording
Profile: DVD-RW restricted overwrite
Profile: DVD-RAM
Profile: DVD-R sequential recording
Profile: DVD-ROM
Profile: CD-RW
Profile: CD-R
Profile: CD-ROM (current)
Profile: Removable Disk
Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr).
Driver flags : MMC-3 SWABAUDIO BURNFREE
Supported modes: TAO PACKET SAO SAO/R96R RAW/R16 RAW/R96P RAW/R96R
Drive buf size : 370688 = 362 KB
Current Secsize: 2048

Capacity Blklen/Sparesz. Format-type Type
344662 2048 0x00 Formatted Media
first: 1 last 26
track: 1 lba: 0 ( 0) 00:02:00 adr: 1 control: 0 mode: -1
track: 2 lba: 21240 ( 84960) 04:45:15 adr: 1 control: 0 mode: -1
track: 3 lba: 32275 ( 129100) 07:12:25 adr: 1 control: 0 mode: -1
track: 4 lba: 46315 ( 185260) 10:19:40 adr: 1 control: 0 mode: -1
track: 5 lba: 62012 ( 248048) 13:48:62 adr: 1 control: 0 mode: -1
track: 6 lba: 81010 ( 324040) 18:02:10 adr: 1 control: 0 mode: -1
track: 7 lba: 91277 ( 365108) 20:19:02 adr: 1 control: 0 mode: -1
track: 8 lba: 101475 ( 405900) 22:35:00 adr: 1 control: 0 mode: -1
track: 9 lba: 111215 ( 444860) 24:44:65 adr: 1 control: 0 mode: -1
track: 10 lba: 122517 ( 490068) 27:15:42 adr: 1 control: 0 mode: -1
track: 11 lba: 137110 ( 548440) 30:30:10 adr: 1 control: 0 mode: -1
track: 12 lba: 154967 ( 619868) 34:28:17 adr: 1 control: 0 mode: -1
track: 13 lba: 164405 ( 657620) 36:34:05 adr: 1 control: 0 mode: -1
track: 14 lba: 175410 ( 701640) 39:00:60 adr: 1 control: 0 mode: -1
track: 15 lba: 185952 ( 743808) 41:21:27 adr: 1 control: 0 mode: -1
track: 16 lba: 205217 ( 820868) 45:38:17 adr: 1 control: 0 mode: -1
track: 17 lba: 215187 ( 860748) 47:51:12 adr: 1 control: 0 mode: -1
track: 18 lba: 228492 ( 913968) 50:48:42 adr: 1 control: 0 mode: -1
track: 19 lba: 247135 ( 988540) 54:57:10 adr: 1 control: 0 mode: -1
track: 20 lba: 260337 ( 1041348) 57:53:12 adr: 1 control: 0 mode: -1
track: 21 lba: 271947 ( 1087788) 60:27:72 adr: 1 control: 0 mode: -1
track: 22 lba: 284040 ( 1136160) 63:09:15 adr: 1 control: 0 mode: -1
track: 23 lba: 299572 ( 1198288) 66:36:22 adr: 1 control: 0 mode: -1
track: 24 lba: 311372 ( 1245488) 69:13:47 adr: 1 control: 0 mode: -1
track: 25 lba: 322405 ( 1289620) 71:40:55 adr: 1 control: 0 mode: -1
track: 26 lba: 331485 ( 1325940) 73:41:60 adr: 1 control: 0 mode: -1
track:lout lba: 344662 ( 1378648) 76:37:37 adr: 1 control: 0 mode: -1

Execution completed.​

The control parameter will show whether the track has pre-emphasis indicated by the TOC. Above, all tracks are "0", but "1" (or "3" if also "digital copy permitted") should be indicated for pre-emphasis:

/*
* Control nibble bits:
*

* 0: with preemphasis (audio) / incremental (data)
* 1: digital copy permitted
* 2: data (not audio) track
* 3: 4 channels (not 2)

*/

#define TM_PREEM 0x1 /* Audio track with preemphasis */
#define TM_INCREMENTAL 0x1 /* Incremental data track */
#define TM_ALLOW_COPY 0x2 /* Digital copy permitted */
#define TM_DATA 0x4 /* This is a data track */
#define TM_QUADRO 0x8 /* Four channel audio */

/*
* Adr nibble:
*/

#define ADR_NONE 0 /* Sub-Q mode info not supplied */
#define ADR_POS 1 /* Sub-Q encodes position data */
#define ADR_MCN 2 /* Sub-Q encodes Media Catalog Number */
#define ADR_ISRC 3 /* Sub-Q encodes ISRC */
​

I can rip that 26-track 77-minute CD in under three minutes; I can't imagine jumping to every track to just read part of it will be that much faster to discover the subcode (true) preemphasis:



(in case you are wondering about the 4-channel option, it was never described or implemented in redbook, and then later it was a "commercial use" bit that also was never implemented.)

 

Sigh.

Your original post in this thread referenced this hydrogen audio post:

cdda2wav doesn't seem to read subcode pre-emphasis info correctly for some CDs

Here are some excerpts:

To summarize:

- In CUERipper, the .cue file (a.k.a. "CUE report") is generated in seconds.
- The .cue file reports the presence of pre-emphasis on a track-by-track basis.
- CUERipper successfully recognized the track-by-track PRE flags on a disc that did not have pre-emphasis flags in the TOC.

I wrote:

"Whatever algorithm CUERipper uses to "read" the subcode, to search for pre-emphasis flags, is -- indeed -- very efficient."

You wrote:

How are you drawing this conclusion?

EDIT:

You wrote:

Okay. I see. You are surmising that it doesn't seem "imaginable" that CUERipper could read the subcode that fast, even though there is solid anecdotal data that suggests it can, and does. Perhaps you quibble with the term "instantaneous" (and it's a fair point that I probably introduced it, but ... in my defense ... I also used "a few seconds" ... and feel those are essentially synonymous in the context of a three-minute rip). Am I still missing something?

 

CUERipper first scans the disc to figure out gaps before doing the actual rip. I assume that during that gap detection scan it also checks if there is a pre-emphasis flag in the subcode for each track.

We have the source code. So I could find out for sure. But I'm lazy and the code isn't documented.

 

Yes, it does.

In Windows, I can open an Explorer Window to view the file contents of the CUERipper output directory. The .cue file "appears" (meaning the software closes the file) immediately after gap detection, so this is a very likely assumption (the .cue file includes the results of the subcode scan for the pre-emphasis flags).

Thanks @Ham Sandwich!

 

The solution to your issue, which still requires you to press a button, is to pick lossless->tak. Cueripper doesn't include that encoder, so you get an error after the cue file but before much audio is ripped.

You can also mess around with the encoder parameters in %appdata%\CUE Tools\profile-verify.txt to break other encoders.

 

But when CUERipper encounters a gap that cannot be detected within a few seconds, the whole process stops. Any already detected gaps are then discarded and the log will say "Gap handling: Not detected, thus appended to previous track." In this case pre-emphasis detection would be incomplete.

 

this is exactly how I do it when I suspect a disc to have PE, however I notice sometimes in these cases that the gap timings can vary slightly from the .cue sheet indicated by EAC. So I only use it to confirm which tracks have PRE flags and which don’t, then add them to a corrected copy of the EAC generated cue sheet.
It is a rather inelegant solution. I wish this feature wasn’t removed from EAC, if cueripper can legally include it then I don’t see why the developer of EAC would be at risk by including it as well.

I do have a few CDs with PE on some tracks and no PE on others. I think you vastly underestimate how many PE discs are out there.

 

I have had CUERipper crash trying to rip certain discs. Not common, but it can happen. It's not as robust as EAC in handling errors and problems. Yet. The developer is working on it and improving the code.

When you got the gap detection error did you try ripping with a different drive (different brand) to see if the other drive could detect the gaps on the CD?

It does look like CUERipper detects the pre-emphasis during the gap detection (index detection) pass.
If you look in the help file for the options for extraction there is an entry that says:

Detect Indexes (gaps) {drop-down list} - Click setting to change.
True = CUERipper will attempt to find (if any) the INDEX 00 position (start of silence or pregap) for each track.
False = Turns detection off. This also disables detection of pre-emphasis flags.​

If you disable index detection (gap detection) then pre-emphasis doesn't get detected.

 

Thanks, that's important info!

Gap detection really is a weak point of CUERipper. Obviously there's only one method of detection implemented and if this fails, there'll be no INDEX 0 data at all.
Also, it fails quite easily. I'd say that on average it takes CUERipper only about five seconds of unsuccessful gap detection to abandon the whole process, which is not very robust.

EAC, in contrast, offers three detection methods and three levels of detection accuracy (secure/accurate/inaccurate) of gap detection - and as long as the method is configured correctly, at least inaccurate will 100% always succeed.

 

What I'm doing when CUERipper cannot detect gaps on a disc is:

- Delete the (useless) CUE sheet.
- Use EAC to detect gaps and generate CUE sheet.
- Copy the EAC cue sheet into the folder containing the CUERipper rip.
- Use CUETools' "encode" option to create a "correct" rip of the CD. (CUETools will detect EAC's CUE sheet and will incorporate it accordingly.)

So I'm simply making use of EAC's better gap detection, instead of using a different drive.

 

Good idea. It's part of my workflow now. It's not elegant, but it's more graceful than pressing that second button (i.e., "Abort").

 

Amen. It's astounding. And a huge hassle for the "digitized" music collector.