DiscImageCreator
DiscImageCreator copied to clipboard
saramibreak
Wrong LEAD-OUT in .cue file with multisession cd-rom / PX-760A drive
Version Latest, 20220301
Describe the bug With my drive/pc it seems all multisession cd-roms get an invalid .cue file when dumped with DIC. DIC says it's succesfully dumped and indeed all goes well, but the .cue / .bin files generated have file table problems when opened with IsoBuster or PowerIso. When dumped with ImgBurn, although it's not readed in raw mode, the cue/bin are functional. It seems to be related with LEAD-OUT
This is the .cue file generated by DIC:
REM SESSION 01
FILE "TOVENARY (Track 1).bin" BINARY
TRACK 01 AUDIO
INDEX 01 00:00:00
REM LEAD-OUT 01:30:00
REM SESSION 02
REM LEAD-IN 01:00:00
REM PREGAP 00:02:00
FILE "TOVENARY (Track 2).bin" BINARY
TRACK 02 MODE2/2352
INDEX 01 00:00:00
This is the .cue file generated by ImgBurn for the same cd-rom:
FILE "tovenarij.bin" BINARY
REM SESSION 01
TRACK 01 AUDIO
INDEX 01 00:00:00
REM LEAD-OUT 03:24:40
REM SESSION 02
TRACK 02 MODE2/2352
INDEX 01 05:56:40
This is the DIC .cue editted to make it open succesfully again:
REM SESSION 01
FILE "TOVENARY (Track 1).bin" BINARY
TRACK 01 AUDIO
INDEX 01 00:00:00
REM LEAD-OUT 03:24:40
REM SESSION 02
REM LEAD-IN 01:00:00
REM PREGAP 00:02:00
FILE "TOVENARY (Track 2).bin" BINARY
TRACK 02 MODE2/2352
INDEX 01 00:00:00
So when using the LEAD-OUT value from ImgBurn it all works again. I'm not very technical at this but I hope this report is useful to help improving DIC
Screenshots
This is how it looks when opening with the original cue file from DIC (file table problems):
This is after fixing the LEAD-OUT manually to match imgburn's cuefile:
Disc title Tovenarij! (Hybrid disc) cd-rom
URL https://archive.org/details/TOVENARY
Log file Log: logs.zip
Use _img.cue, please. This cue is a general format, while .cue is a redump.org specific format. Other app can't support it completely.
So DIC uses a specific .cue format that most popular iso software can not open?
Can't DIC perhaps have an option to create 2 .cue formats: one that works with generic iso software and one that fits the redump cue format? It seems in this case changing a few values makes it work again with popular iso software and that greatly helps people/archivists with little technical knowledge. But I'm not sure if it works with every multisession cd-rom. In my area about 1 of every 50 old secondhand cd-rom's are multisession, they may be rare but I still come across them quite often.
If it's a bug from IsoBuster, the dev in my experience is friendly and probably open to discuss it and perhaps improve the software
For anyone who is interested in this topic, someone pointed me to this discussion about the redump multisession cue format: http://forum.redump.org/post/94441/#p94441
So DIC uses a specific .cue format that most popular iso software can not open?
Yes, multiple bin itself is the redump.org specific, though. I say again, please use the clone cd format (ccd+img+sub+cue) if you want to use the multi-session disc by the other app.
If it's a bug from IsoBuster
It's not a bug, IsoBuster merely has not supported the redump cue.
For anyone who is interested in this topic
PREGAP 02:32:00 is completely incorrect. Lead-out and Lead-in area, which it's 01:30:00 + 01:00:00, are not the pregap.
@saramibreak I am still not having any luck with mounting a DIC-produced multisession disc image with IsoBuster.
For example, I dumped this Counting Crows - Hard Candy Enhanced CD (multisession disc), and when I try to open the ccd/img/sub, it doesn't show the ISO9660 file system when it should exist:
If I try to open the _img.cue file, it doesn't work at all:
I also upgraded to IsoBuster 5.0, and have the same issues. In fact, now it does not show anything for the data track when opening the ccd file:
Counting Crows - Hard Candy_logs.zip
Use _img.cue, please. This cue is a general format, while .cue is a redump.org specific format. Other app can't support it completely.
I'm not an expert on this topic, but I think the multi-bin cues might not contain all the info necessary as the IsoBuster dev tried to add support for our cues. Would be great if you could get in dialog with him, he's a nice guy https://www.isobuster.com/support.php
Hi All,
I addressed this CUE 'issue' in IsoBuster 5.0 to the best of my knowledge. Without having read the details in this thread, issues exist(ed) because the LEAD-OUT entry in the CUE is/was wrong or absent !
A correct LEAD-OUT is a must in all IsoBuster versions < 5.0 (also ImgBurn etc.) Without it and without it being correct, the second session address will be identified wrongly. Do know that the address is also relative to the file start, so it depends on whether you have one or more files referenced by the CUE
A missing LEAD-OUT is now 'allowed' in IsoBuster >= 5.0 IF the second or later session is in its own file (or set of files). IsoBuster is then usually able to get it right based on file length etc.
When I looked into this, triggered by people active in redump.org, and from what I remember (*), it was only an issue in CUE files. I was not aware there were *.CCD issues. In fact I'd have to look into CCD altogether to refresh my memory (*) on the format.
(*) I have the memory of a goldfish
In case of the counting crows CD image. Do you have 14 files ? If so, try removing the REM LEAD-OUT entry from the CUE. Does it work now in IsoBuster 5.0 ? (It won't in IsoBuster 4.9.1)
I might also add that I (in IsoBuster) was the very first person ever to support multi-session CUE+ISO/IMG/BIN files and as such I set/created the standard .. So .. when I say it's wrong .. it's wrong ! LOL
In case of the counting crows CD image. Do you have 14 files ? If so, try removing the REM LEAD-OUT entry from the CUE. Does it work now in IsoBuster 5.0 ? (It won't in IsoBuster 4.9.1)
I think that worked! I removed REM LEAD-OUT 01:30:00 from the 14-bin cuesheet and now the file system looks sane. I wonder what would need to change for the img/ccd/sub to be parsed correctly, or for the cuesheet with the merged bin (img) to be parsed correctly.
I wonder what would need to change for the img/ccd/sub to be parsed correctly, or for the cuesheet with the merged bin (img) to be parsed correctly.
Can you elaborate ? With IsoBuster ?
With merged bin do you mean to say you'd like all files in one big file with a CUE ? That is easy, since IsoBuster creates single file iso/bin files from a CD. Right mouse click the top most CD/DVD icon in the left pane and select Extract <image> Make sure a CUE is created as well (settings) or create it separately (also via top icon right click) IsoBuster will put the correct LEAD-OUT in the CUE (if IsoBuster correctly parses the file system - which it seems to do based on the screenshot)
Currently, IsoBuster is unable to parse the file system correctly based on the img/ccd/sub that is produced by DIC from a multisession disc. In other words, what would need to be changed in the ccd file?
Currently, IsoBuster is unable to parse the file system correctly based on the img/ccd/sub that is produced by DIC from a multisession disc. In other words, what would need to be changed in the ccd file?
Care to upload a set of files somewhere ?
Care to upload a set of files somewhere ?
https://1fichier.com/?rsbyaoyqddb1ngo6opnl
Thank you, I will have a look as soon as I can. Question, why the two CUE variants ? A CUE for a single *.img container and a CUE for a set of *.bin files ? (both flawed it seems)
Thank you, I will have a look as soon as I can. Question, why the two CUE variants ? A CUE for a single *.img container and a CUE for a set of *.bin files ? (both flawed it seems)
https://github.com/saramibreak/DiscImageCreator/issues/121#issuecomment-1077882557
I'm going to have a look tomorrow, to try and figure things out. For my understanding, is the *.ccd in its current form, as generated by DIC, actually properly supported by CloneCD ?
EDIT, I'll answer this myself:
For my understanding, is the *.ccd in its current form, as generated by DIC, actually properly supported by CloneCD ?
No, this particular multi-session-CD *.CCD won't work with CloneCD or other applications (virtual drivers) that support CCD
It turned out providing a bit of context and a proper explanation (see below) was more work than the actual analysis ;)
OK, I've done my analysis based on the counting crows' CD images and here are the results. I'm trying to be as objective as possible without pointing fingers. This stuff has always been the wild west.
I'll break it up in three parts, to try and keep some level of overview.
- CUE + multiple BIN files
- CUE + single IMG file
- CCD + single IMG file
The short:
-
CUE + multiple BIN files: The DIC generated CUE's LEAD-OUT address is wrong
-
CUE + single IMG file: The DIC generated CUE's LEAD-OUT address is correct but the DIC generated IMG is missing 11400 blocks
-
CCD + single IMG file: The DIC generated CCD's last track address is wrong On top of that there is an IsoBuster 5.0 64bit bug (not in 4.x nor 5.0 32bit) but it doesn't matter here since the CCD is wrong anyway
The Long:
- CUE + multiple BIN files:
REM SESSION 01
FILE "Counting Crows - Hard Candy (Track 01).bin" BINARY
TRACK 01 AUDIO
ISRC USIR10211155
INDEX 01 00:00:00
FILE "Counting Crows - Hard Candy (Track 02).bin" BINARY
TRACK 02 AUDIO
ISRC USIR10211068
INDEX 01 00:00:00
FILE "Counting Crows - Hard Candy (Track 03).bin" BINARY
TRACK 03 AUDIO
ISRC USIR10211153
INDEX 01 00:00:00
FILE "Counting Crows - Hard Candy (Track 04).bin" BINARY
TRACK 04 AUDIO
ISRC USIR10211157
INDEX 01 00:00:00
FILE "Counting Crows - Hard Candy (Track 05).bin" BINARY
TRACK 05 AUDIO
ISRC USIR10211154
INDEX 01 00:00:00
FILE "Counting Crows - Hard Candy (Track 06).bin" BINARY
TRACK 06 AUDIO
ISRC USIR10211151
INDEX 00 00:00:00
INDEX 01 00:00:65
FILE "Counting Crows - Hard Candy (Track 07).bin" BINARY
TRACK 07 AUDIO
ISRC USIR10211158
INDEX 01 00:00:00
FILE "Counting Crows - Hard Candy (Track 08).bin" BINARY
TRACK 08 AUDIO
ISRC USIR10211159
INDEX 01 00:00:00
FILE "Counting Crows - Hard Candy (Track 09).bin" BINARY
TRACK 09 AUDIO
ISRC USIR10211152
INDEX 00 00:00:00
INDEX 01 00:01:25
FILE "Counting Crows - Hard Candy (Track 10).bin" BINARY
TRACK 10 AUDIO
ISRC USIR10211150
INDEX 00 00:00:00
INDEX 01 00:01:70
FILE "Counting Crows - Hard Candy (Track 11).bin" BINARY
TRACK 11 AUDIO
ISRC USIR10211161
INDEX 00 00:00:00
INDEX 01 00:00:63
FILE "Counting Crows - Hard Candy (Track 12).bin" BINARY
TRACK 12 AUDIO
ISRC USIR10211160
INDEX 00 00:00:00
INDEX 01 00:00:35
FILE "Counting Crows - Hard Candy (Track 13).bin" BINARY
TRACK 13 AUDIO
ISRC USIR10211277
INDEX 01 00:00:00
REM LEAD-OUT 01:30:00
REM SESSION 02
REM LEAD-IN 01:00:00
REM PREGAP 00:02:00
FILE "Counting Crows - Hard Candy (Track 14).bin" BINARY
TRACK 14 MODE1/2352
INDEX 01 00:00:00
First some necessary information:
1.1
A multi-session CUE needs a correct 'REM LEAD-OUT' entry to be properly supported. I introduced multi-session support in CUE files probably ~20 years ago now and I laid down the law :)
IsoBuster versions <= 4.9 will not deal with the image correctly if the 'REM LEAD-OUT' entry is missing
Same for other applications, for instance ImgBurn:
1.1.1
One exception to 1.1: as of IsoBuster 5.0 the total absense of 'REM LEAD-OUT' is allowed in CUE + multi-file images.
The start address of the LEAD-OUT is then derived from the file-size associated with the last track of the session.
This works if the LEAD OUT truly follows the track. If not, make sure to include a POSTGAP
1.2
MSF addresses are relative to the start of the file they're in.
I find that a bit counter-intuitive as well, especially when trying to preserve an identical layout, but it's how CDRWin's Jeff concieved it back in the days.
This is also why in this CUE file you will see INDEX 01 00:00:00 for every track, because every track is located in its own file.
The MSF address 00:00:00 is relative to the start of each file.
1.3 The ISO9660 file system and its derivatives (Joliet, Rock Ridge etc.) use absolute addressing internally ! In other words, an ISO9660 file system in a second session uses addressing relative to the start address of the first session (which is 0), not relative to the start address of the session it is in. This is different for HFS for instance. If the session containing an HFS file system gets assigned a different address from the original CD, it will still work, because it's relative to the start of the session. Not for ISO9660 and Joliet. This is why the address of the first data track in the second session here needs to be at the exact same address as the original. If it's not, the ISO9660 file system will not parse correctly. While this can be seen as a pest, in this case it's a blessing, because you have an excellent indirect way to test if the image is identical (in layout) than the original. After all it is what led to this thread.
1.4 According to the various CD standards the pre-gap of the very first track on a CD starts at MSF: 00:00:00 MSF stands for Minutes:Seconds:Frames. A second contains 75 frames. A minute contains 60 seconds. You do the math :) The actual first Logical Block Address (LBA) of the track starts 150 blocks/frames later. So LBA 0 = MSF 00:02:00 HOWEVER the creator of the CUE format, CDRWin's Jeff, in all his wisdom (ahum), decided to make LBA 0 = MSF 00:00:00 as well. Essentially ignoring the first track's pregap This is just information that is not that important as long as you compare apples to apples ! As long as you're working with the CUE alone you don't need to worry about this too much. However if you consider CDD as well and CloneCD Oliver's correct implementation of MSF, then you need to take this difference in account (see 3.)
As a consequence of 1.2 the 'REM LEAD-OUT' address is also relative to the start of the file associated with the last track of the session ( FILE "Counting Crows - Hard Candy (Track 13).bin" BINARY )
The 'REM LEAD-OUT' entry follows the 'FILE' entry and hence is part of it.
And since the disc LEAD-OUT immediately follows the track (here) the (relative to file) LEAD-OUT address is essentially the size of track 13.
After removing the 'REM LEAD-OUT' entry from this CUE (see 1.1.1), after loading the CUE in IsoBuster 5.0 and after being able to properly parse the ISO9660 file system (see 1.3) I now know the exact address of the first track of the second session.
I know the layout is properly identified now. Based on this information I can also calculate the proper LEAD-OUT MSF address ! Namely the size of track 13.
Either by doing the math (see before) or by right mouse clicking the track in IsoBuster and by selecting "Extract From-To" where you can see the MSF size of the track:
BEFORE THE CUE-file FIX:
FIX the LEAD-OUT address in the CUE, change it to:
REM LEAD-OUT 08:45:20
'Et Voila', the CUE + BIN files now works in IsoBuster 4.x and other applications (for instance ImgBurn)
- CUE + single IMG file:
Counting Crows - Hard Candy_img.cue
FILE "Counting Crows - Hard Candy.img" BINARY
REM SESSION 01
TRACK 01 AUDIO
ISRC USIR10211155
INDEX 01 00:00:00
TRACK 02 AUDIO
ISRC USIR10211068
INDEX 01 04:20:55
TRACK 03 AUDIO
ISRC USIR10211153
INDEX 01 08:53:05
TRACK 04 AUDIO
ISRC USIR10211157
INDEX 01 13:17:22
TRACK 05 AUDIO
ISRC USIR10211154
INDEX 01 17:10:17
TRACK 06 AUDIO
ISRC USIR10211151
INDEX 00 21:26:65
INDEX 01 21:27:55
TRACK 07 AUDIO
ISRC USIR10211158
INDEX 01 24:15:70
TRACK 08 AUDIO
ISRC USIR10211159
INDEX 01 29:17:02
TRACK 09 AUDIO
ISRC USIR10211152
INDEX 00 33:07:12
INDEX 01 33:08:37
TRACK 10 AUDIO
ISRC USIR10211150
INDEX 00 37:11:15
INDEX 01 37:13:10
TRACK 11 AUDIO
ISRC USIR10211161
INDEX 00 41:05:42
INDEX 01 41:06:30
TRACK 12 AUDIO
ISRC USIR10211160
INDEX 00 45:44:17
INDEX 01 45:44:52
TRACK 13 AUDIO
ISRC USIR10211277
INDEX 01 50:52:25
REM LEAD-OUT 59:37:45
REM SESSION 02
TRACK 14 MODE1/2352
INDEX 01 62:09:45
The CUE file appears to be correct. The 'REM LEAD-OUT' entry is correct. The data track 'INDEX' address is correct too. Both are relative to the start of the only file (Counting Crows - Hard Candy.img). See 1.2 for the explanation.
We know it is correct because we have a working CUE + BIN files now (See 1.) (by either removing 'REM LEAD-OUT' or by fixing 'REM LEAD-OUT' and giving it address '08:45:20'
When we load that CUE in IsoBuster and right mouse click the top most CD icon in the left pane and select "Create Cue sheet file" we can generate a CUE for a single file image, because that is the format IsoBuster always chooses.
In that generated CUE file we can see the LEAD-OUT address matches the LEAD-OUT address in the DIC created CUE (same for data track INDEX).
FILE "CD [countingcrows].iso" BINARY
REM ORIGINAL MEDIA-TYPE: CD
REM SESSION 01 (*)
TRACK 01 AUDIO
ISRC USIR10211155
INDEX 01 00:00:00
REM LBA: 0
TRACK 02 AUDIO
ISRC USIR10211068
INDEX 01 04:20:55
REM LBA: 19555
TRACK 03 AUDIO
ISRC USIR10211153
INDEX 01 08:53:05
REM LBA: 39980
TRACK 04 AUDIO
ISRC USIR10211157
INDEX 01 13:17:22
REM LBA: 59797
TRACK 05 AUDIO
ISRC USIR10211154
INDEX 01 17:10:17
REM LBA: 77267
TRACK 06 AUDIO
ISRC USIR10211151
INDEX 00 21:26:65
REM LBA: 96515
INDEX 01 21:27:55
REM LBA: 96580
TRACK 07 AUDIO
ISRC USIR10211158
INDEX 01 24:15:70
REM LBA: 109195
TRACK 08 AUDIO
ISRC USIR10211159
INDEX 01 29:17:02
REM LBA: 131777
TRACK 09 AUDIO
ISRC USIR10211152
INDEX 00 33:07:12
REM LBA: 149037
INDEX 01 33:08:37
REM LBA: 149137
TRACK 10 AUDIO
ISRC USIR10211150
INDEX 00 37:11:15
REM LBA: 167340
INDEX 01 37:13:10
REM LBA: 167485
TRACK 11 AUDIO
ISRC USIR10211161
INDEX 00 41:05:42
REM LBA: 184917
INDEX 01 41:06:30
REM LBA: 184980
TRACK 12 AUDIO
ISRC USIR10211160
INDEX 00 45:44:17
REM LBA: 205817
INDEX 01 45:44:52
REM LBA: 205852
TRACK 13 AUDIO
ISRC USIR10211277
INDEX 01 50:52:25
REM LBA: 228925
REM LEAD-OUT 59:37:45 (*)
REM SESSION 02 (*)
TRACK 14 MODE1/2352
INDEX 01 62:09:45
REM LBA: 279720
REM (*) SESSION commands are not supported by all applications
REM Generated by IsoBuster 5.0.0.00 (https://www.isobuster.com)
So why doesn't it work ? Because the IMG file misses 11400 blocks !
The session overhead, lead-out, lead-in and pregap of the first track in the second session are completely omitted from the image.
There is no mechanism in CUE + IMG image files to omit these blocks from an image file. CUE knows PREGAP and POSTGAP, but they only apply to tracks and need to be placed at strict positions in the CUE
If you work with a single container file you cannot simply omit blocks from the middle, it messes with the addressing. Any application will look for the second-session data at a wrong offset inside the file.
It would only be theoretically possible if a command would exist for it (say 'GAP 02:32:00). But the standard does not provide this command and if an application chooses to use this mechanism it should at the very least introduce this (or a similar) command in the CUE to alert other applications.
As an FYI, the Clone CD *.CCD associated container image file ommits these 11400 blocks. But CCD is another format in its own right. It's not called CUE and it contains different data. So an application is aware of this feature and can take it in account. I realize this IMG is created for the associated CCD file in the file set ! And for the purpose of CCD it is created correctly. But one should remove the CUE for it (in case of multi-session), since CUE and CCD expect different things from their container files (especially in the case of multi-session discs). It just ads to the confusion.
- CCD + single IMG file:
The IMG file is correct and created in a way that is expected for CCD files (see 2. last paragraph)
However the CCD file is not correct ! The start address of the data track in the second session is 870 blocks off from reality. 870 blocks is an odd number that I can't immediately correlate with something, so I'm not sure where it comes from ?
PS. CCD is just another text format (an INI file in fact)
The last '[Entry]' is the entry for the last track. Which is the data track in the second session here. In this image it's [Entry21]
[Entry 21]
Session=2
Point=0x0e
ADR=0x01
Control=0x04
TrackNo=0
AMin=0
ASec=0
AFrame=0
ALBA=-150
Zero=0
PMin=62
PSec=0
PFrame=0
PLBA=278850
IsoBuster uses the PMin, PSec and PFrame values to determine the track start address.
The PLBA value is ignored but needs to be a correct translation of the MSF address of course.
If you have a look at the IsoBuster Created CUE (See 2. second paragraph) you can see the correct address for the track. It is: 279720 (REM LBA: 279720) or CUE-MFS 62:09:45 (INDEX 01 62:09:45)
See how I refer to the CUE-MSF here, because it's 150 frames or 2 seconds off from a true CD-standard MSF address (see 1.4) In other words the true MSF address of the track is 62:11:45
Fix the CCD in this file set and you have a working CCD + IMG !!! ((*) With one exception, see below)
[Entry 21]
Session=2
Point=0x0e
ADR=0x01
Control=0x04
TrackNo=0
AMin=0
ASec=0
AFrame=0
ALBA=-150
Zero=0
PMin=62
PSec=11
PFrame=45
PLBA=279720
(*) It appears IsoBuster 5.0 64-bit has an issue as it doesn't parse the CCD correctly ! The problem does not exist in the 32-bit version, nor in the lower versions (e.g. 4.x) It's a conversion bug (5.0 is the first 64 bit version - it took quite a bit of work) It was a simple fix and I have a test version for those who'd like it. Otherwise you'll find it in next official Beta and of course IsoBuster 5.1
Multi-BIN: I think your understanding of REM LEAD-OUT differs to ours. You assume that REM LEAD-OUT is a total gap size between sessions. We assume that gap between sessions is a sum of 3 sizes: REM LEAD-OUT REM LEAD-IN REM PREGAP
We can't change meaning of LEAD-OUT tag because it doesn't represent physical layout of the disc, even if it loads in IsoBuster.
CUE + multiple BIN files:
The DIC generated CUE's LEAD-OUT address is wrong
It's not wrong. (https://github.com/saramibreak/DiscImageCreator/issues/121#issuecomment-1077882557) (https://github.com/saramibreak/DiscImageCreator/issues/121#issuecomment-1078584116)
CUE + single IMG file:
The DIC generated CUE's LEAD-OUT address is correct but the DIC generated IMG is missing 11400 blocks
It's a specification. Other apps also do not generate 11400 blocks.
CCD + single IMG file:
The DIC generated CCD's last track address is wrong
On top of that there is an IsoBuster 5.0 64bit bug (not in 4.x nor 5.0 32bit) but it doesn't matter here since the CCD is wrong anyway
Surely the PSec and PFrame of your ccd file are wrong. But I dumped a multi-session disc by the latest release version and it's no problem. If you say it's a bug, use "Bug report" from "New Iisue", please.
Multi-BIN: I think your understanding of REM LEAD-OUT differs to ours. You assume that REM LEAD-OUT is a total gap size between sessions. We assume that gap between sessions is a sum of 3 sizes: REM LEAD-OUT REM LEAD-IN REM PREGAP
With specifications there really is only one interpretation. The LEAD-OUT is an address. It is where the lead-out starts, followed by a lead-in and pregap. It is not a size or range, it is an address. The address is relative to the start of the FILE entry that precedes it.
We can't change meaning of LEAD-OUT tag because it doesn't represent physical layout of the disc, even if it loads in IsoBuster.
I'm not sure what you mean by that.
Ok, so in the image @tjanas uploaded, the multi-BIN CUE says this:
REM LEAD-OUT 01:30:00
Please explain how you interpret this value ?
The way it needs to be interpreted, and the way other implementations interpret this (e.g. ImgBurn), the lead-out starts 1 minute and 30 seconds into FILE "Counting Crows - Hard Candy (Track 13).bin"
However, that file (track) is 8 minutes, 45 seconds and 20 frames long.
So .. how does that compute ?
If an application were to use 01:30:00 it would cut track 13 short, start the lead-out too soon and position track 14 wrong, which is essentially what happens and why other applications can't mount your CUE + multi-BIN
Mind you, in the single-IMG CUE the LEAD-OUT value is correct !
It's not wrong. (#121 (comment)) (#121 (comment))
Yes, multiple bin itself is the redump.org specific,
I see.
Then it's an unfortunate choice of file extension (*.cue).
Or at the very least REM LEAD-OUT could have been named slightly differently, so that apps understanding this command would not interpret it as intended and as a result misinterpret the format.
Or, as last resort, add 'REM Created with Redump' (or something to that effect) so that applications know they should ignore the REM LEAD-OUT entry.
It's a specification. Other apps also do not generate 11400 blocks.
Apps do what they want with their own format, but should adhere to standards set for other formats. You can't omit sectors from a container and expect the CUE to still work with it. No application that interprets the CUE properly works with this format. I tried a few.
Fact is that CloneCD's *.CCD relies on the 11400 sectors being omitted and so if you generate a correct CCD then that is fine. CCD and this type IMG work fine together. But remove the *.CUE, because the CUE cannot work with this IMG container (when it's a multi-session disc)
Surely the PSec and PFrame of your ccd file are wrong. But I dumped a multi-session disc by the latest release version and it's no problem. If you say it's a bug, use "Bug report" from "New Iisue", please.
I worked with the uploaded image from @tjanas. Download it and notice the address of the data track is recorded wrongly in the CCD file. I can't comment on other releases or other CDs. I'm just providing feedback on the files shown to me, to try and help out with feedback because the confusion in your community is huge. I have been getting emails regarding redump and multi-session CDs for a long time now.
I believe I used a fairly recent version of DIC to dump this disc. If there is a newer version than the one I used that will produce different cue/ccd files, I will give that a try and report back with those differences.
Multi-BIN: I think your understanding of REM LEAD-OUT differs to ours. You assume that REM LEAD-OUT is a total gap size between sessions. We assume that gap between sessions is a sum of 3 sizes: REM LEAD-OUT REM LEAD-IN REM PREGAP
With specifications there really is only one interpretation. The LEAD-OUT is an address. It is where the lead-out starts, followed by a lead-in and pregap. It is not a size or range, it is an address. The address is relative to the start of the FILE entry that precedes it.
We can't change meaning of LEAD-OUT tag because it doesn't represent physical layout of the disc, even if it loads in IsoBuster.
I'm not sure what you mean by that.
Ok, so in the image @tjanas uploaded, the multi-BIN CUE says this:
REM LEAD-OUT 01:30:00Please explain how you interpret this value ?
The way it needs to be interpreted, and the way other implementations interpret this (e.g. ImgBurn), the lead-out starts 1 minute and 30 seconds into FILE "Counting Crows - Hard Candy (Track 13).bin" However, that file (track) is 8 minutes, 45 seconds and 20 frames long. So .. how does that compute ? If an application were to use 01:30:00 it would cut track 13 short, start the lead-out too soon and position track 14 wrong, which is essentially what happens and why other applications can't mount your CUE + multi-BIN
Mind you, in the single-IMG CUE the LEAD-OUT value is correct !
Let me look into this one more time to refresh my knowledge on it. I will get back to you here. I'm focusing only on Multi-BIN CUE as this is the preservation format we use at redump.
The LEAD-OUT is an address. It is where the lead-out starts, followed by a lead-in and pregap. It is not a size or range, it is an address. The address is relative to the start of the FILE entry that precedes it.
Isobuster uses LEAD-OUT in that way, but redump cue with multi bin is not so.
We had been disscussed in redump forum about the multi session cue. http://forum.redump.org/topic/20409/done-discussing-the-multisession-cue/
If you can't agree to the multi session cue of redump, contact F1ReB4LL and iR0b0t and Jackal, please. If they agree to your opinion, I'll change the LEAD-OUT.
Multi-BIN: I think your understanding of REM LEAD-OUT differs to ours. You assume that REM LEAD-OUT is a total gap size between sessions. We assume that gap between sessions is a sum of 3 sizes: REM LEAD-OUT REM LEAD-IN REM PREGAP
With specifications there really is only one interpretation. The LEAD-OUT is an address. It is where the lead-out starts, followed by a lead-in and pregap. It is not a size or range, it is an address. The address is relative to the start of the FILE entry that precedes it.
We can't change meaning of LEAD-OUT tag because it doesn't represent physical layout of the disc, even if it loads in IsoBuster.
I'm not sure what you mean by that.
Ok, so in the image @tjanas uploaded, the multi-BIN CUE says this:
REM LEAD-OUT 01:30:00Please explain how you interpret this value ?
The way it needs to be interpreted, and the way other implementations interpret this (e.g. ImgBurn), the lead-out starts 1 minute and 30 seconds into FILE "Counting Crows - Hard Candy (Track 13).bin" However, that file (track) is 8 minutes, 45 seconds and 20 frames long. So .. how does that compute ? If an application were to use 01:30:00 it would cut track 13 short, start the lead-out too soon and position track 14 wrong, which is essentially what happens and why other applications can't mount your CUE + multi-BIN
Mind you, in the single-IMG CUE the LEAD-OUT value is correct !
All right, so here is one multi-BIN example:
REM SESSION 01
FILE "Hear It Here First! (USA) (Track 1).bin" BINARY
TRACK 01 AUDIO
INDEX 01 00:00:00
FILE "Hear It Here First! (USA) (Track 2).bin" BINARY
TRACK 02 AUDIO
INDEX 00 00:00:00
INDEX 01 00:01:19
FILE "Hear It Here First! (USA) (Track 3).bin" BINARY
TRACK 03 AUDIO
INDEX 00 00:00:00
INDEX 01 00:01:53
REM LEAD-OUT 01:30:00
REM SESSION 02
REM LEAD-IN 01:00:00
REM PREGAP 00:02:00
FILE "Hear It Here First! (USA) (Track 4).bin" BINARY
TRACK 04 MODE2/2352
INDEX 01 00:00:00
First of all, data disc Multi-BIN is an invention of redump.org mostly. That's our way of managing the database and there is a lot of sense in this scheme such as matching audio tracks across regions and maintaining a compatibility of reproducing the disc when writing 1:1, with, possibly, write offset deviation, but that's another story. What applies to Single-IMG, doesn't apply to Multi-BIN.
In our case, LEAD-OUT tag is a property of the SESSION, it doesn't "belong" to the last file of the session.
I agree with you that maybe reusing existing CUE tag names to express a different meaning is not a good idea. The discussion on that happened years ago and changing anything at this point will have a huge impact on a lot of things: redump.org DB, user archives, archive.org, rom managers, hardware CD emulators such as PSX PSIO, X-Station, Dreamcast MODE and gdemu.
When it comes to IsoBuster, from what I understand, our users frustration comes mainly from not being able to browse multisession data track contents in your application (because data track is using absolute sector offset as you mentioned earlier). I have a number of solutions how that can be implemented:
- If you see more than one FILE entry in the CUE-sheet - it's redump.org (C) Multi-BIN CUE sheet and you can interpret our tags (LEAD-IN, LEAD-OUT, PREGAP) differently, like I explained in my previous comment.
- A variety of (1) where you check if all 3 tags exist (LEAD-IN, LEAD-OUT, PREGAP), if so - it's redump.org (C) Multi-BIN CUE sheet
- You don't need CUE-sheet at all. Go over track BIN's, detect if the track is a data track and use first sector MSF as a reference point when you interpret directory records, like here: https://github.com/superg/redump_info/blob/master/src/image_browser.cc#L104
We had been disscussed in redump forum about the multi session cue. http://forum.redump.org/topic/20409/done-discussing-the-multisession-cue/
Interesting, even though I merely scanned the other post just now. I think @Jackal was on the ball. If you wanted to do something unique, you should have called it something unique I also feel the true purpose of LEAD-OUT wasn't really (fully) understood. It's just an address to show where the LEAD-OUT (and hence also LEAD-IN and PREGAP) starts (since these sizes are fixed per the CD standard). I wish I had been drawn into that discussion, it could have saved years of confusion.
Water under the bridge
I'll change the LEAD-OUT.
Probably adds even more to the confusion with different flavors in play