Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Trouble with CUE sheets (once again...) (Read 5714 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Trouble with CUE sheets (once again...)

Hi folks.

(First off: This seems like a long post, but it's not. So please don't stop reading until you see the CODE blocks - those only concern Case.  )

Since I'm starting a newly layed out collection, I'm trying to decide on the type of CUE sheet to use, and would appreciate some advice. There are 3 options:


1) EAC's "noncompliant" CUE sheets, which match the separate MPC or WAV files (i.e., the gap mode is correct, the CUE sheet specifies gaps at the end of files, which is where they are).

This is a problem because I'm reluctant to use EAC's burning function (it constantly produces coasters even with my drive which has a buffer underrun protection), and Burrrn doesn't work either. So while this option may be the only one that matches the files, the CUE sheets wouldn't be of much use to me and I'd end up burning CDs without using them anyway.


2) "Multiple WAV files with corrected gaps". This is actually incompatible with the files (since it specifies that the gaps be at the beginning of the files, when in fact they're not), but since mppdec can comfortably decode all files referenced in an .m3u playlist into a single large WAV file (by using mppdec playlist.m3u range.wav) and the CUE sheet can be converted to match this big image file using cuefix, this is not too big a problem. At least I could use the CUE sheet at all.

But apart from the fact that using cuefix is an unnecessary step (I could just use option 3), I have concerns about this method which I will explain further below.


3) CUE sheet for a single wave file. This sounds like the best option so far - just decode the MPC album using mppdec playlist.m3u range.wav and use the CUE sheet. This should work, shouldn't it? The track indexes should still be correct even after decoding the MPC files, since MPC doesn't alter the length of files (?).



Now, about my concerns for cuefix (this mainly concerns Case, if you're reading it ). In theory, a CUE sheet generated by cuefix should be identical with a CUE sheet for one large image file, right?

It's not. Take a look at this:


This is what the single file CUE sheet created by EAC looks like:

Code: [Select]
PERFORMER "Dire Straits"
TITLE "Love Over Gold"
FILE "Range.wav" WAVE
  TRACK 01 AUDIO
    TITLE "Telegraph Road"
    PERFORMER "Dire Straits"
    INDEX 00 00:00:00
    INDEX 01 00:00:32
  TRACK 02 AUDIO
    TITLE "Private Investigations"
    PERFORMER "Dire Straits"
    INDEX 00 14:18:25
    INDEX 01 14:18:72
  TRACK 03 AUDIO
    TITLE "Industrial Disease"
    PERFORMER "Dire Straits"
    INDEX 00 21:04:35
    INDEX 01 21:05:62
  TRACK 04 AUDIO
    TITLE "Love Over Gold"
    PERFORMER "Dire Straits"
    INDEX 00 26:53:65
    INDEX 01 26:56:15
  TRACK 05 AUDIO
    TITLE "It Never Rains"
    PERFORMER "Dire Straits"
    INDEX 00 33:10:55
    INDEX 01 33:13:17



cuefix created this CUE sheet:

Code: [Select]
PERFORMER "Dire Straits"
TITLE "Love Over Gold"
FILE "Range.wav" WAVE
  TRACK 01 AUDIO
    TITLE "Telegraph Road"
    PERFORMER "Dire Straits"
    PREGAP 00:00:32
    INDEX 01 00:00:00
  TRACK 02 AUDIO
    TITLE "Private Investigations"
    PERFORMER "Dire Straits"
    INDEX 00 14:17:68
    INDEX 01 14:18:40
  TRACK 03 AUDIO
    TITLE "Industrial Disease"
    PERFORMER "Dire Straits"
    INDEX 00 21:04:03
    INDEX 01 21:05:30
  TRACK 04 AUDIO
    TITLE "Love Over Gold"
    PERFORMER "Dire Straits"
    INDEX 00 26:53:33
    INDEX 01 26:55:58
  TRACK 05 AUDIO
    TITLE "It Never Rains"
    PERFORMER "Dire Straits"
    INDEX 00 33:10:23
    INDEX 01 33:12:60


If you paste both of those into separate text editor windows and switch between the two with [ALT]+[TAB], you will see the differences. Where does the PREGAP flag on track 1 come from, and why are the times slightly off?

I'm totally baffled at this. Since cuefix gets the exact track lengths from the MPC files, this leads me to assume that they're somehow different than on the original CD - which, I was thinking, shouldn't happen with MPC.

Now, where is the problem? Is it really that the track lengths are different (in that case, option 2) would be preferable, i.e., the CUE sheet created by cuefix would be more exact), or is cuefix doing something wrong (which would make option 3) the better solution)? I really don't know.

I'd be grateful for some insight here.


In case this might be of need, here is the original "Multiple WAV files with corrected gaps" CUE sheet:

Code: [Select]
PERFORMER "Dire Straits"
TITLE "Love Over Gold"
FILE "01 - Telegraph Road.wav" WAVE
  TRACK 01 AUDIO
    TITLE "Telegraph Road"
    PERFORMER "Dire Straits"
    INDEX 00 00:00:00
    INDEX 01 00:00:32
FILE "02 - Private Investigations.wav" WAVE
  TRACK 02 AUDIO
    TITLE "Private Investigations"
    PERFORMER "Dire Straits"
    INDEX 00 00:00:00
    INDEX 01 00:00:47
FILE "03 - Industrial Disease.wav" WAVE
  TRACK 03 AUDIO
    TITLE "Industrial Disease"
    PERFORMER "Dire Straits"
    INDEX 00 00:00:00
    INDEX 01 00:01:27
FILE "04 - Love Over Gold.wav" WAVE
  TRACK 04 AUDIO
    TITLE "Love Over Gold"
    PERFORMER "Dire Straits"
    INDEX 00 00:00:00
    INDEX 01 00:02:25
FILE "05 - It Never Rains.wav" WAVE
  TRACK 05 AUDIO
    TITLE "It Never Rains"
    PERFORMER "Dire Straits"
    INDEX 00 00:00:00
    INDEX 01 00:02:37


CU

Dominic

Trouble with CUE sheets (once again...)

Reply #1 –
Quote
This is a problem because I'm reluctant to use EAC's burning function (it constantly produces coasters even with my drive which has a buffer underrun protection), and Burrrn doesn't work either.

Could you be more specific?

Trouble with CUE sheets (once again...)

Reply #2 –
I can't remember exactly what went wrong, I'll have to try again. All I remember is that it said it started burrrning (the CD writer wasn't doing anything though), and after some seconds, when the CD writer had started writing, it stopped with an error message, and left me with a coaster.

I'm using a Lite-On LTR-48246S. (I didn't bother to read any of the cdrdao docs, so perhaps it's a driver problem I'm unaware of...)

Trouble with CUE sheets (once again...)

Reply #4 –
I doubt your problem with burrrn is to do with the non compliant cuesheet.  cdrdao should have quit with an error before starting to write if there was a problem.

I have a Liteon 48x and use burnatonce (obviously since I am the developer! ) which in turn uses cdrdao.  I have had no problem writing non compliant eac cuesheets although I have to admit I have only done so while testing.

I suggest you try burrrn (or burnatonce) again with an eac non compliant cuesheet.  If that doesn't work please try adding the tracks manually to rule out any other problems. 

Jamie

Trouble with CUE sheets (once again...)

Reply #5 –
Sorry for the long delay, I had somehow missed this post...

Quote
Now, about my concerns for cuefix (this mainly concerns Case, if you're reading it ). In theory, a CUE sheet generated by cuefix should be identical with a CUE sheet for one large image file, right?

It's not. Take a look at this:
...

The difference here is caused by short pregap in your first track, this is not stored at all in your MPC files and thus must be replaced with silence (PREGAP command). If you compare directly ripped CDImage.wav and Range.wav decoded from MPCs you'll notice that Range.wav is shorter by that pregap amount.
When there are is no pregap in first track cue sheets should be identical.

Trouble with CUE sheets (once again...)

Reply #6 –
A-ha! Thanks for the clarification. So in other words, keeping the "Corrected Gaps" CUE sheet is the better option after all. (Damn, I've ranted about PiMP so many times for recommending this mode - now it all makes sense! )


jamieo:

I never said the trouble with Burrrn had anything to do with the CUE sheet.  I was just stating that EAC's noncompliant CUE sheets aren't of much use to me if all burning apps that support them don't work on my system.

But I'll surely try to investigate why Burrrn (or cdrdao, for that matter) isn't working correctly. I have a strong suspicion that my VIA chipset could be the culprit here (as usual when I have problems with any IDE device - for example, my system will crash if I rip with C2 enabled in EAC, or if I have the drive set to Ultra DMA instead of Multiword DMA).

CU

Dominic

Trouble with CUE sheets (once again...)

Reply #7 –
Quote
I never said the trouble with Burrrn had anything to do with the CUE sheet.

Sorry, I misinterpreted your original statement. 

A common cause of coasters with cdrdao are due to the fact that it does not lock the writer device (burnatonce does though ) so another app accessing the drive will abort the write with the misleading error message 'buffer underrrun?'.  Please try again and report the error message. 

Jamie

Trouble with CUE sheets (once again...)

Reply #8 –
I don't think any other program was accessing the drive (also, I have the auto-insert notification disabled). But as I said, I'll try to find out what's causing trouble.

I'm downloading burnatonce right now.

Trouble with CUE sheets (once again...)

Reply #9 –
Jamie,

I have just tried burnatonce on a CD-RW, and it didn't work.  Here's the cdrdao log:

Code: [Select]
Cdrdao version 1.1.7 - (C) Andreas Mueller <andreas@daneb.de>
  SCSI interface library - (C) Joerg Schilling
  Paranoia DAE library - (C) Monty

Using libscg version 'andreas-0.5-UNIXWARE_Patch'

1,1,0: LITE-ON LTR-48246S    Rev: SS0A
Using driver: Generic SCSI-3/MMC - Version 2.0 (options 0x0010)

Starting write at speed 12...
Turning BURN-Proof on
Executing power calibration...
Power calibration successful.
Writing track 01 (mode MODE1/MODE1 )...
?: I/O error.  : scsi sendcmd: retryable error
CDB:  2A 00 00 00 01 C2 00 00 1A 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: 70 00 00 00 00 00 00 0A 00 00 00 00 00 00
Sense Key: 0x0 No Additional Sense, Segment 0
Sense Code: 0x00 Qual 0x00 (no additional sense information) Fru 0x0
Sense flags: Blk 0 (not valid) 
cmd finished after 0.002s timeout 180s
ERROR: Write data failed.
ERROR: Writing failed - buffer under run?
ERROR: Writing failed.


I dunno... does this suggest a chipset problem?

[EDIT] Forgot to mention: I'm using Win98 SE, and have ASPI 4.60 installed. [/EDIT]

(And could someone perhaps split this thread? This has nothing to do with the original topic  Or perhaps we should continue discussion at the burnatonce forum...)

Trouble with CUE sheets (once again...)

Reply #10 –
Did you try the raw driver?  The raw driver is recommended for liteon drives but should not be essential...

TBH, I don't understand the meaning of this error so I recommend you post the log to the cdrdao mailing list if the raw driver does not work. 

Jamie

Trouble with CUE sheets (once again...)

Reply #11 –
Quote
If you compare directly ripped CDImage.wav and Range.wav decoded from MPCs you'll notice that Range.wav is shorter by that pregap amount.

If there is a session pregap (pregap before first track), this should be visible in the gap column of EAC (on the line of the first gap). (Right?)

Well then there is something I don't get. For several of my CDs EAC lists such a session pregap, but this session pregap is not ripped, nor is it included in the Cue sheet (single WAV cue sheet of course). The cue sheet says 'index01 00:00:00'

Quote
FILE "CDImage.wav" WAVE
  TRACK 01 AUDIO
    TITLE "Track01"
    PERFORMER "Unknown"
    INDEX 01 00:00:00


If it is true that the session pregap is included in the image, I expect index01 00:02:00 (this is the number  EAC displays)

Trouble with CUE sheets (once again...)

Reply #12 –
Hmm, you're right. But I think I've found an explanation.

A CD *must* have a 2 second pregap AFAIK - most CDs I've seen so far seem to stick with that. I just tested a CD for which EAC showed an exact 2 second pre-gap in the "gap" column - no INDEX 00 in the CUE sheet.

Then I tested the CD I used for describing my problem above - the gap length displayed is 0:00:02.32 (with "Display times using frames" enabled). The .32 reappears in the CUE sheet:

Code: [Select]
FILE "Range.wav" WAVE
  TRACK 01 AUDIO
    TITLE "Telegraph Road"
    PERFORMER "Dire Straits"
    ISRC GBFO88400779
    INDEX 00 00:00:00
    INDEX 01 00:00:32


So I guess this is it, I'm quite sure. A 2 sec pregap is included automatically upon burning any CD, and the CUE sheet just specifies anything that exceeds the 2 seconds. If anyone in the know could give a confirmation to be 100% certain...

Trouble with CUE sheets (once again...)

Reply #13 –
Quote
Hmm, you're right. But I think I've found an explanation.

A CD *must* have a 2 second pregap AFAIK - most CDs I've seen so far seem to stick with that. I just tested a CD for which EAC showed an exact 2 second pre-gap in the "gap" column - no INDEX 00 in the CUE sheet.

Then I tested the CD I used for describing my problem above - the gap length displayed is 0:00:02.32 (with "Display times using frames" enabled). The .32 reappears in the CUE sheet:

Code: [Select]
FILE "Range.wav" WAVE
  TRACK 01 AUDIO
    TITLE "Telegraph Road"
    PERFORMER "Dire Straits"
    ISRC GBFO88400779
    INDEX 00 00:00:00
    INDEX 01 00:00:32


So I guess this is it, I'm quite sure. A 2 sec pregap is included automatically upon burning any CD, and the CUE sheet just specifies anything that exceeds the 2 seconds. If anyone in the know could give a confirmation to be 100% certain...

There MUST be a 2 second pregap before the FIRST track.

Trouble with CUE sheets (once again...)

Reply #14 –
That's exactly what I meant to say. I could have made it more obvious that I was talking only about the first track, but essentially, I was saying exactly that.
 

Trouble with CUE sheets (once again...)

Reply #15 –
Riddle solved! Thank you Volcano

Quote
So I guess this is it, I'm quite sure. A 2 sec pregap is included automatically upon burning any CD, and the CUE sheet just specifies anything that exceeds the 2 seconds. If anyone in the know could give a confirmation to be 100% certain...  

And I guess that only these exceeding  music sectors can be added to the WAV. Not if you rip a range (or just tracks), but yes if you create an image.
I couldn't find a CD with more than sec pregap to verify this, but
Quote
If anyone in the know could give a confirmation to be 100% certain...


(otherwise I'll report as soon as I encounter such a disk)