IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
Trouble with CUE sheets (once again...), ...and concerns about cuefix [@Case]
Volcano
post May 21 2003, 19:04
Post #1





Group: Members (Donating)
Posts: 916
Joined: 30-September 01
From: Berlin, Germany
Member No.: 112



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. tongue.gif smile.gif)

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 smile.gif). 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
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
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
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
Go to the top of the page
+Quote Post
Gambit
post May 25 2003, 12:37
Post #2


Burrrn developer


Group: Developer
Posts: 917
Joined: 25-November 01
From: Bratislava, Slovakia
Member No.: 534



QUOTE (Volcano @ May 21 2003 - 07:04 PM)
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?


--------------------
Burrrn - http://www.burrrn.net/
MPEG Audio Collection - http://mac.sourceforge.net/
Go to the top of the page
+Quote Post
Volcano
post May 25 2003, 13:04
Post #3





Group: Members (Donating)
Posts: 916
Joined: 30-September 01
From: Berlin, Germany
Member No.: 112



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...)
Go to the top of the page
+Quote Post
Gambit
post May 25 2003, 13:12
Post #4


Burrrn developer


Group: Developer
Posts: 917
Joined: 25-November 01
From: Bratislava, Slovakia
Member No.: 534



Hmm, I have a 40x LiteOn so it should work.


--------------------
Burrrn - http://www.burrrn.net/
MPEG Audio Collection - http://mac.sourceforge.net/
Go to the top of the page
+Quote Post
jamieo
post May 25 2003, 13:42
Post #5





Group: Members
Posts: 52
Joined: 6-August 02
Member No.: 2956



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! wink.gif) 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. smile.gif

Jamie

This post has been edited by jamieo: May 25 2003, 16:09
Go to the top of the page
+Quote Post
Case
post May 25 2003, 14:17
Post #6





Group: Developer (Donating)
Posts: 2292
Joined: 19-October 01
From: Finland
Member No.: 322



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 smile.gif). 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.
Go to the top of the page
+Quote Post
Volcano
post May 25 2003, 17:44
Post #7





Group: Members (Donating)
Posts: 916
Joined: 30-September 01
From: Berlin, Germany
Member No.: 112



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! smile.gif)


jamieo:

I never said the trouble with Burrrn had anything to do with the CUE sheet. unsure.gif 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
Go to the top of the page
+Quote Post
jamieo
post May 26 2003, 10:03
Post #8





Group: Members
Posts: 52
Joined: 6-August 02
Member No.: 2956



QUOTE (Volcano @ May 25 2003 - 04:44 PM)
I never said the trouble with Burrrn had anything to do with the CUE sheet. unsure.gif

Sorry, I misinterpreted your original statement. smile.gif

A common cause of coasters with cdrdao are due to the fact that it does not lock the writer device (burnatonce does though wink.gif) 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. smile.gif

Jamie
Go to the top of the page
+Quote Post
Volcano
post May 26 2003, 19:40
Post #9





Group: Members (Donating)
Posts: 916
Joined: 30-September 01
From: Berlin, Germany
Member No.: 112



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. smile.gif
Go to the top of the page
+Quote Post
Volcano
post May 29 2003, 08:15
Post #10





Group: Members (Donating)
Posts: 916
Joined: 30-September 01
From: Berlin, Germany
Member No.: 112



Jamie,

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

CODE
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 wink.gif Or perhaps we should continue discussion at the burnatonce forum...)

This post has been edited by Volcano: May 29 2003, 08:20
Go to the top of the page
+Quote Post
jamieo
post May 29 2003, 18:15
Post #11





Group: Members
Posts: 52
Joined: 6-August 02
Member No.: 2956



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. smile.gif

Jamie
Go to the top of the page
+Quote Post
liekloo
post Jun 8 2003, 15:06
Post #12





Group: Members
Posts: 456
Joined: 22-March 02
From: Belgium
Member No.: 1596



QUOTE (Case @ May 25 2003 - 02:17 PM)
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)

This post has been edited by liekloo: Jun 8 2003, 15:20


--------------------
"E S S E N T I A L" Guide for E A C :

http://users.fulladsl.be/spb2267/
Go to the top of the page
+Quote Post
Volcano
post Jun 8 2003, 22:08
Post #13





Group: Members (Donating)
Posts: 916
Joined: 30-September 01
From: Berlin, Germany
Member No.: 112



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
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... smile.gif
Go to the top of the page
+Quote Post
Gambit
post Jun 9 2003, 12:09
Post #14


Burrrn developer


Group: Developer
Posts: 917
Joined: 25-November 01
From: Bratislava, Slovakia
Member No.: 534



QUOTE (Volcano @ Jun 8 2003 - 10:08 PM)
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
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... smile.gif

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


--------------------
Burrrn - http://www.burrrn.net/
MPEG Audio Collection - http://mac.sourceforge.net/
Go to the top of the page
+Quote Post
Volcano
post Jun 9 2003, 18:33
Post #15





Group: Members (Donating)
Posts: 916
Joined: 30-September 01
From: Berlin, Germany
Member No.: 112



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.
Go to the top of the page
+Quote Post
liekloo
post Jun 9 2003, 20:50
Post #16





Group: Members
Posts: 456
Joined: 22-March 02
From: Belgium
Member No.: 1596



Riddle solved! Thank you Volcano smile.gif

QUOTE (Volcano @ June9)
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... smile.gif 

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... smile.gif

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

This post has been edited by liekloo: Jun 9 2003, 20:52


--------------------
"E S S E N T I A L" Guide for E A C :

http://users.fulladsl.be/spb2267/
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 22nd December 2014 - 16:49