mirror of
https://github.com/aaru-dps/Aaru.git
synced 2026-02-04 00:54:33 +00:00
Aaru to CDRWin has incorrect INDEX 01 offset #660
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @terinjokes on GitHub (Feb 1, 2021).
Prerequisites
Check and fill as appropriate:
Description
When converting a CDDA to CDRWin's BIN+CUE format, I've noticed that Track 1 often starts abruptly, not how I remember the CD starting. The generated Cue sheet reports the audio starting at 2 seconds, which is about 1.5 seconds after the audio actually seems to start.
aaru media info /dev/sr0aaru media dump -O compress=false --eject --fix-offset --subchannel none /dev/sr0 cd.aaruaaru image info cd.aaruaaru image convert -f cd.aaru cd2.cuecat cd2.cueHowever it's clear the the audio is starting earlier than 00:02:00 by opening the raw file in audacity.
If I'm using aaru wrong, that's fine, I haven't made a lot of progress, but I'd like to learn that now than later. Is this related to my drive not being in the drive database?
Edit: I get the same issue when I providing the
--first-pregapoption toaaru media dump.@claunia commented on GitHub (Feb 1, 2021):
Please paste the output of
aaru image info cd.aarufand the output ofcat cd2.cue.Also please indicate the manufacturer, model, and firmware revision, of the drive used to dump.
@terinjokes commented on GitHub (Feb 1, 2021):
The outputs of those two commands are already included above. As noted in
aaru image info, this drive is an HP DVD-RAM GH40L with firmware RB12. I've included the output ofaaru device infobelow.aaru device info /dev/sr0hp_DVD-RAM GH40L_RB12.json.gz
@claunia commented on GitHub (Feb 1, 2021):
Ok I'll take a look
@terinjokes commented on GitHub (Feb 1, 2021):
Thanks! I've been reading the code, but not familiar with it yet to debug and implement a patch myself. If I can answer any questions, let me know.
@claunia commented on GitHub (Feb 1, 2021):
The problem is that in
472a1d94d8/Aaru.Core/Devices/Dumping/CompactDisc/Dump.cs (L1047)it is not finding your drive in the database.I have checked and it is in the server's database, you can check in your local database to see if it is there.
@terinjokes commented on GitHub (Feb 1, 2021):
I ran
aaru database update --clear-alland I see that section now reports a drive offset:However the Cue sheet still reports
00:02:00as the beginning of track 1, and the audio still starts before this point in the BIN file when viewed in Audacity.@terinjokes commented on GitHub (Feb 1, 2021):
16e043cedd/Aaru.Core/Media/Info/CompactDisc.cs (L150-L152)Looks like my device reports false here?
"CanReadCdScrambled": false,@claunia commented on GitHub (Feb 1, 2021):
nothing to do with the problem.
Seems there is a problem with cue generation.
The earliest the index 1 of track 1 can start is 00:02:00 (LBA 0), however CDRWin Cuesheet considers 00:00:00 as the start of the file (this is LBA 0).
So what really, in the disc is:
in the cuesheet should be:
The bug is therefore in this method:
16e043cedd/Aaru.Images/CDRWin/Write.cs (L410)@terinjokes commented on GitHub (Feb 2, 2021):
The INDEX 00 gets added here, when the track has a pregap.
16e043cedd/Aaru.Images/CDRWin/Write.cs (L520-L529)150 frames (as we can see in
aaru image info) is 2 seconds (assuming 75 frames/second), which is the area for the TOC. So this seems accurate, however, per a user on the hydrogenaudio forums:It seems like the correct behavior might be to change this to a PREGAP if aaru doesn't include that audio in the data? Or change the condition to only add the INDEX 00 if the pregap is longer than 150? I'll be hesitant to make such a change without understanding what aaru does for gaps between tracks.
Sorry, if I'm barking up the wrong tree.
For sake of comparison, I also ripped with
cdrdaoto see what it was doing.cdrdao read-cd --datafile cdrdao-cd.bin cdrdao-cd.toccat cdrdao-cd.toccat cdrdao-cd.cueThe raw file looks the same however, so I agree the Cue sheet generation is the likely culprit here.
@claunia commented on GitHub (Feb 2, 2021):
The solution for the bug is to not write an index 00 for track 1, and displace the LBA to MSF 150 sectors.
On discs, LBA 0 == MSF 00:02:00, LBA -150 = MSF 00:00:00.
On cuesheet, LBA 0 == MSF 00:00:00, it doesn't store negative LBAs.
@terinjokes commented on GitHub (Feb 2, 2021):
This is not the solution because INDEX 00 for track 1 is where HTOA is represented.
@claunia commented on GitHub (Feb 2, 2021):
Sorry, what do you mean with HTOA?
@FakeShemp commented on GitHub (Feb 2, 2021):
Hidden track
@claunia commented on GitHub (Feb 2, 2021):
I have not been able to get CDRWin or IsoBuster to properly dump any disc with a hidden track, tried with a CD-i Ready and an audio one.
@FakeShemp you had one, can you try and see what CDRWin 3/4 generates for INDEX 0, if any?
@TheRogueArchivist commented on GitHub (Feb 3, 2021):
Cue file generated by Isobuster from a CD with a hidden track (i-trax):
Media info:
@claunia commented on GitHub (Feb 3, 2021):
Ok so correct behaviour is to put INDEX 00 in the CUE when the pregap is bigger than 150 sectors and INDEX 01 with 2 seconds less.
So:
Track 1 index 0 => 00:00:00 (LBA -150)
Track 1 Index 1 => 02:35:15 (LBA 6992)
Cue:
While:
Track 1 index 0 => 00:00:00 (LBA -150)
Track 1 index 1 => 00:02:00 (LBA 0)
Cue:
That solves the hidden tracks case.