Closed hcs64 closed 1 year ago
It's correct. MSF of tracks cue uses relative time, while MSF of img.cue uses absolute time.
sarami, you're correct with this statement. But the problem here is that this disc TOC track 1 starts from lba 37 (index 1), but when you do a track split, you start with lba 0. Due to 37 index 0 sectors prepended to Track 1, your index timepoints are all shifted 37 sectors in relation to track 1. In the past, I had a discussion with other mods, where should track 1 split start if it's not LBA 0 in toc, and Fireball responded that we should always start from lba 0, which DIC does correctly, just the index entries have to be corrected.
Thanks sarami, let me try to explain better. I think the img .cue is correct to say index 1 goes from 00:00:37 to 00:12:02. But this is inconsistent with the track .cue, where index 1 goes from 00:00:37 to 00:11:40, unless some frames are missing from index 1 in the track .bin (I don't think that is the case).
For track 1, nLBAofFirstIdx
is set to the start of index 1, but there's some index 0 sectors in track 1 on this disc. You have a special case to output indexes 0 and 1, but later indexes are relative to nLBAofFirstIdx
, which is the start of index 1, past the start of the track.
So this only occurs when track 1 contains both index 0 and 2.
MSF of tracks cue uses relative time
Ok, correctly, MSF of tracks cue uses absolute time from the each track, not relative time.
test version DiscImageCreator_test.zip
That looks good for track 1!
But, now track 3 looks like this in the tracks .cue:
FILE "VDR-5222 (Track 3).bin" BINARY
TRACK 03 AUDIO
INDEX 01 00:00:00
INDEX 02 35:11:47
INDEX 03 37:21:47
INDEX 04 40:37:65
INDEX 05 41:14:55
INDEX 06 41:47:50
It looks like index 2+ is absolute. I think these were correct before in 20221217:
FILE "VDR-5222 (Track 3).bin" BINARY
TRACK 03 AUDIO
INDEX 01 00:00:00
INDEX 02 04:44:27
INDEX 03 06:54:27
INDEX 04 10:10:45
INDEX 05 10:47:35
INDEX 06 11:20:30
Thanks again, happy new year!
This looks good for VDR-5222, thanks!
But the problem has moved to other tracks with index 0 and 2:
Battle Gear: The Discovery of Roads (ZTTL-0054, redump, Amazon) has index 0-3 on track 10. With the test above (20230101T151119, logs) this gives:
FILE "ZTTL-0054 (Track 10).bin" BINARY
TRACK 10 AUDIO
INDEX 00 00:00:00
INDEX 01 00:03:22
INDEX 02 00:12:39
INDEX 03 02:43:12
I think it was correct before as:
FILE "ZTTL-0054 (Track 10).bin" BINARY
TRACK 10 AUDIO
INDEX 00 00:00:00
INDEX 01 00:03:22
INDEX 02 00:09:17
INDEX 03 02:39:65
That was consistent with the img.cue:
TRACK 10 AUDIO
INDEX 00 17:49:05
INDEX 01 17:52:27
INDEX 02 17:58:22
INDEX 03 20:28:70
Index 2 is 00:09:17 (692 frames) past index 0.
Looks good for everything I tested! VDR-5222 now seems correct, and everything else correctly matches the older versions.
Beyond VDR-5222 and ZTTL-0054 mentioned above, I tested INTIR-013 (Rockman 9 OST, many indexes including 0 on tracks 34 and 35) and PSCX-1005 (Final Fantasy III Legend of the Eternal Wind, index 1-2 on track 1). If you want the subchannel logs for any of these let me know.
If you want the subchannel logs for any of these let me know.
Yes, please.
https://shivermetimbe.rs/files/dumplogs/issue_172_logs.7z
These are all using the last DiscImageCreator_test.zip you posted here.
SQEX 10042 is Final Fintasy VII: Reunion Tracks (redump), notable for having a long hidden track.
Version 20221217
Describe the bug On Namco Video Game Graffiti Vol. 2, the split track cuesheet has track 1 indexes 02 and above at different time than in the whole disc image. They're off by 37 frames, which is index 01, so seems that the indexes are relative to index 01 instead of the beginning of the track. This seems to only be an issue on track 1 when index 01 is past 00:00:00.
This seems to be rare, I've not found another example of a disc like this.
Screenshots
tracks cue:
img.cue:
Disc title Namco Video Game Graffiti Vol. 2 Cat. no. VDR-5222
Disc ringcode
VDR-5222-1-A1E
URL Amazon: https://a.co/d/beEJ4qY
Log file VDR-5222_dic_test_20221217.zip