aaru-dps/Aaru-aaru-dps
1
0
Fork 0
mirror of https://github.com/aaru-dps/Aaru.git synced 2026-02-04 00:54:33 +00:00
Code Issues 657 Packages Projects Releases 19 Wiki Activity

Audio CDs with very large amounts of data in lead-in (44,100+ samples) that aren't offsets #852

New Issue
Open
opened 2026-01-29 15:30:58 +00:00 by claunia · 3 comments
claunia commented 2026-01-29 15:30:58 +00:00
Owner
Copy Link

Originally created by @intothisworld on GitHub (Dec 15, 2021).

Originally assigned to: @claunia on GitHub.

Version

5.3.0

Commit hash

No response

Tested debug version?

  • Yes

Which operating systems have you used?

  • Windows
  • Linux
  • macOS
  • Other

What is the architectural bit size you're using?

  • 32-bit
  • 64-bit
  • Unsure or unknown

What processor are you using?

  • An Intel or AMD
  • An ARM or Apple Silicon
  • Unsure or unknown

Device manufacturer

Plextor

Device model

PX-760A and PX-W4012TU

Bus the device uses to attach to the computer

  • Parallel ATA
  • Serial ATA
  • SCSI (any)
  • ATAPI (mark above if parallel or serial)
  • USB
  • FireWire
  • PCMCIA
  • SecureDigital
  • MultiMediaCard

USB cable or card reader manufacturer

No response

USB cable or card reader model

No response

What were you doing when it failed?

  • I was dumping media (disk, tape, etc)...
  • I was retrieving media (disk, tape, etc) information...
  • I was scanning media (disk, tape, etc)...
  • I was retrieving device information...

Description

I've been doing some tests for a new version of DIC and have stumbled upon quite a few discs with what seemed at first like massive offsets in the lead-in sectors. Tried to simply offset a couple of them and got less-than-ideal results. In a few cases, the alignment of the tracks got totally messed up (tracks cutting off early and transitioning while song is still finishing), and in others, the data at the end of the disc got pushed out into the lead-out and was thus cut off in the dump. Is it possible we need to extend the dumping range to capture the extra data in these cases, rather than simply offsetting it?

The most notable example I've discovered is disc 3 of the SaGa Frontier soundtrack. That one is also interesting because it's a hidden track 1 pre-gap song, and also the data that sticks out into the lead-in is part of the actual music (the track starts in the middle of the first couple notes of the song). Here are logs for a regular .aaruf dump, as well as a dump with the --first-pregap true flag added.
SaGaFrontier-Aaruf.zip
SaGaFrontier-Aaruf --first-pregap True.zip

Exact command line used

Aaru m dump E: SaGaFrontier.aaruf --first-pregap True

Expected behavior

Aaru to recognize that there was a huge amount of data in the LBA -150 to -1 range and append it to the beginning of the dump. Also perhaps the ability to recognize the difference between a situation that requires just a simple offset and a situation that requires an actual extension of the dump range. No idea what trickery you might be able to pull off to determine that...

Actual behavior

Both versions of the dump seemed to just cover the typical standard dumping range of the disc. Tested the resulting .aaruf files in RedBookPlayer and the cut-off first couple seconds of the pre-gap track were unable to be reached via typical rewinding for HTOA stuff. Converted the .aaruf file to bin/cue and then to FLAC, and the cut-off seconds at the beginning weren't available that way either. See logs above in description box for standard and --first-pregap true flagged dump.

Command output text wouldn't fit in the following box, so the text file is attached here instead:
SaGa Frontier with -d flag debug.txt

Output of command execution with debug output enabled

See box above.

Media details

A few discs I've found with tons of data in the lead-in (and the number of samples that show up there):

Dune Messiah (audiobook, several discs) [disc 1 = 44,111 samples / ~75 sectors]
Adjusting as a regular offset pushes 44,074 samples of data out into the lead-out, as well as causing songs in some tracks to crowd into neighboring tracks.
https://www.bookdepository.com/Dune-Messiah-Frank-Herbert/9781427202369?ref=grid-view&qid=1639533831302&sr=1-38

Getz/Gilberto (50th anniversary) [600 samples / ~1 sector]
Adjusting as a regular offset pushes 54 samples of data out into the lead-out.
https://www.discogs.com/release/9642984-Stan-Getz-Joao-Gilberto-Featuring-Antonio-Carlos-Jobim-Getz-Gilberto-50th-Anniversary-StereoMono

Halo 4 OST [44,112 samples / ~75 sectors]
Adjusting as offset shifts 44,100 samples of data into the lead-out and causes tracks to crowd into other tracks.
https://www.discogs.com/release/6306343-Neil-Davidge-Halo-4-Original-Soundtrack

SaGa Frontier OST (disc 3) [43,355 samples / ~74 sectors]
Adjusting as an offset shifts 29,727 samples of data into the lead-out.
https://www.discogs.com/release/757686-Kenji-Ito-SaGa-Frontier-Original-Soundtrack

Ocarina of Time: The Soundtrack [44,130 samples / ~75 sectors]
Adjusting as an offset causes some tracks to crowd into neighboring tracks.
https://www.discogs.com/release/5688899-Unknown-Artist-Ocarina-Of-Time-The-Soundtrack

Originally created by @intothisworld on GitHub (Dec 15, 2021). Originally assigned to: @claunia on GitHub. ### Version 5.3.0 ### Commit hash _No response_ ### Tested debug version? - [X] Yes ### Which operating systems have you used? - [X] Windows - [ ] Linux - [ ] macOS - [ ] Other ### What is the architectural bit size you're using? - [ ] 32-bit - [X] 64-bit - [ ] Unsure or unknown ### What processor are you using? - [X] An Intel or AMD - [ ] An ARM or Apple Silicon - [ ] Unsure or unknown ### Device manufacturer Plextor ### Device model PX-760A and PX-W4012TU ### Bus the device uses to attach to the computer - [ ] Parallel ATA - [ ] Serial ATA - [ ] SCSI (any) - [ ] ATAPI (mark above if parallel or serial) - [ ] USB - [ ] FireWire - [ ] PCMCIA - [ ] SecureDigital - [ ] MultiMediaCard ### USB cable or card reader manufacturer _No response_ ### USB cable or card reader model _No response_ ### What were you doing when it failed? - [X] I was dumping media (disk, tape, etc)... - [ ] I was retrieving media (disk, tape, etc) information... - [ ] I was scanning media (disk, tape, etc)... - [ ] I was retrieving device information... ### Description I've been doing some tests for a new version of DIC and have stumbled upon quite a few discs with what seemed at first like massive offsets in the lead-in sectors. Tried to simply offset a couple of them and got less-than-ideal results. In a few cases, the alignment of the tracks got totally messed up (tracks cutting off early and transitioning while song is still finishing), and in others, the data at the end of the disc got pushed out into the lead-out and was thus cut off in the dump. Is it possible we need to extend the dumping range to capture the extra data in these cases, rather than simply offsetting it? The most notable example I've discovered is disc 3 of the SaGa Frontier soundtrack. That one is also interesting because it's a hidden track 1 pre-gap song, and also the data that sticks out into the lead-in is part of the actual music (the track starts in the middle of the first couple notes of the song). Here are logs for a regular .aaruf dump, as well as a dump with the `--first-pregap true` flag added. [SaGaFrontier-Aaruf.zip](https://github.com/aaru-dps/Aaru/files/7718053/SaGaFrontier-Aaruf.zip) [SaGaFrontier-Aaruf --first-pregap True.zip](https://github.com/aaru-dps/Aaru/files/7718055/SaGaFrontier-Aaruf.--first-pregap.True.zip) ### Exact command line used Aaru m dump E: SaGaFrontier.aaruf --first-pregap True ### Expected behavior Aaru to recognize that there was a huge amount of data in the LBA -150 to -1 range and append it to the beginning of the dump. Also perhaps the ability to recognize the difference between a situation that requires just a simple offset and a situation that requires an actual extension of the dump range. No idea what trickery you might be able to pull off to determine that... ### Actual behavior Both versions of the dump seemed to just cover the typical standard dumping range of the disc. Tested the resulting .aaruf files in RedBookPlayer and the cut-off first couple seconds of the pre-gap track were unable to be reached via typical rewinding for HTOA stuff. Converted the .aaruf file to bin/cue and then to FLAC, and the cut-off seconds at the beginning weren't available that way either. See logs above in description box for standard and `--first-pregap true` flagged dump. Command output text wouldn't fit in the following box, so the text file is attached here instead: [SaGa Frontier with -d flag debug.txt](https://github.com/aaru-dps/Aaru/files/7718043/SaGa.Frontier.with.-d.flag.debug.txt) ### Output of command execution with debug output enabled ```shell See box above. ``` ### Media details A few discs I've found with tons of data in the lead-in (and the number of samples that show up there): **Dune Messiah (audiobook, several discs)** [disc 1 = 44,111 samples / ~75 sectors] Adjusting as a regular offset pushes 44,074 samples of data out into the lead-out, as well as causing songs in some tracks to crowd into neighboring tracks. https://www.bookdepository.com/Dune-Messiah-Frank-Herbert/9781427202369?ref=grid-view&qid=1639533831302&sr=1-38 **Getz/Gilberto (50th anniversary)** [600 samples / ~1 sector] Adjusting as a regular offset pushes 54 samples of data out into the lead-out. https://www.discogs.com/release/9642984-Stan-Getz-Joao-Gilberto-Featuring-Antonio-Carlos-Jobim-Getz-Gilberto-50th-Anniversary-StereoMono **Halo 4 OST** [44,112 samples / ~75 sectors] Adjusting as offset shifts 44,100 samples of data into the lead-out and causes tracks to crowd into other tracks. https://www.discogs.com/release/6306343-Neil-Davidge-Halo-4-Original-Soundtrack **SaGa Frontier OST (disc 3)** [43,355 samples / ~74 sectors] Adjusting as an offset shifts 29,727 samples of data into the lead-out. https://www.discogs.com/release/757686-Kenji-Ito-SaGa-Frontier-Original-Soundtrack **Ocarina of Time: The Soundtrack** [44,130 samples / ~75 sectors] Adjusting as an offset causes some tracks to crowd into neighboring tracks. https://www.discogs.com/release/5688899-Unknown-Artist-Ocarina-Of-Time-The-Soundtrack
claunia added the bugmedia labels 2026-01-29 15:30:58 +00:00
claunia commented 2026-01-29 15:30:59 +00:00
Author
Owner
Copy Link

@TheRogueArchivist commented on GitHub (Dec 18, 2021):

Would you be able to attach the files outputted when you run the command "media info drive letter -w output" of one or more of these discs please? With "output" just being a name to identify the disc.

@TheRogueArchivist commented on GitHub (Dec 18, 2021): Would you be able to attach the files outputted when you run the command "media info *drive letter* -w output" of one or more of these discs please? With "output" just being a name to identify the disc.
claunia commented 2026-01-29 15:31:02 +00:00
Author
Owner
Copy Link

@intothisworld commented on GitHub (Dec 19, 2021):

Here ya go =)
DuneMessiah-Disc1 m info.zip
Getz-Gilberto m info.zip
Halo4 m info.zip
SaGaFrontier-Disc3 m info.zip
ZeldaOoT m info.zip

@intothisworld commented on GitHub (Dec 19, 2021): Here ya go =) [DuneMessiah-Disc1 m info.zip](https://github.com/aaru-dps/Aaru/files/7740423/DuneMessiah-Disc1.m.info.zip) [Getz-Gilberto m info.zip](https://github.com/aaru-dps/Aaru/files/7740424/Getz-Gilberto.m.info.zip) [Halo4 m info.zip](https://github.com/aaru-dps/Aaru/files/7740425/Halo4.m.info.zip) [SaGaFrontier-Disc3 m info.zip](https://github.com/aaru-dps/Aaru/files/7740426/SaGaFrontier-Disc3.m.info.zip) [ZeldaOoT m info.zip](https://github.com/aaru-dps/Aaru/files/7740427/ZeldaOoT.m.info.zip)
claunia commented 2026-01-29 15:31:03 +00:00
Author
Owner
Copy Link

@intothisworld commented on GitHub (Dec 19, 2021):

Possibly worth noting, just checked all 7 discs of the Dune Messiah audiobook. They all have the same pattern, covering basically the same range of non-zero data. Here's what I found, if this offers any clues into what exactly is happening with these weird discs:

-Disc 1 = non-zero data extends -44,111 samples into lead-in ; if offset is adjusted, pushes end of data out into the lead-out 44,074 samples
-Disc 2 = -44,111 samples ; if offset adjusted, 44,075 into lead-out
-Disc 3 = -44,111 samples ; if offset adjusted, 44,075 into lead-out
-Disc 4 = -44,111 samples ; if offset adjusted, 44,074 into lead-out
-Disc 5 = -44,111 samples ; if offset adjusted, 44,075 into lead-out
-Disc 6 = -44,111 samples ; if offset adjusted, 44,073 into lead-out
-Disc 7 = -44,111 samples ; if offset adjusted, 44,073 into lead-out
@intothisworld commented on GitHub (Dec 19, 2021): Possibly worth noting, just checked all 7 discs of the Dune Messiah audiobook. They all have the same pattern, covering basically the same range of non-zero data. Here's what I found, if this offers any clues into what exactly is happening with these weird discs: -Disc 1 = non-zero data extends -44,111 samples into lead-in ; if offset is adjusted, pushes end of data out into the lead-out 44,074 samples -Disc 2 = -44,111 samples ; if offset adjusted, 44,075 into lead-out -Disc 3 = -44,111 samples ; if offset adjusted, 44,075 into lead-out -Disc 4 = -44,111 samples ; if offset adjusted, 44,074 into lead-out -Disc 5 = -44,111 samples ; if offset adjusted, 44,075 into lead-out -Disc 6 = -44,111 samples ; if offset adjusted, 44,073 into lead-out -Disc 7 = -44,111 samples ; if offset adjusted, 44,073 into lead-out
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
archive
beginner
bug
bug
dependencies
device
device
dump image format
duplicate
Epic
feature request
filesystem
filter
gui
gui
gui
help wanted
invalid
invalid
media
needs triage
partitioning scheme
pull-request
Mirrored from GitHub Pull Request
 upstream
wontfix
No Label bug media
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: aaru-dps/Aaru-aaru-dps#852
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?