Page 1 of 2

audio offset

Posted: Fri Jul 01, 2022 6:44 pm
by superg
EDIT 12/03/2022:

Final Audio CD offset correction algorithm (technical):
1. if there is one and only one possible disc write offset, applying which perfectly aligns audio silence (level: 0) ranges with TOC index 0 ranges, use it
2. else if there is non-zero data in lead-out and that data can be fully shifted out (left) without spanning non-zero data into lead-in, correct offset with a minimum shift required
3. else if there is non-zero data in lead-in and that data can be fully shifted out (right) without spanning non-zero data into lead-out, correct offset with a minimum shift required
4. else apply offset 0

Dump format specification notes:
Regardless of the applied offset, we always operate on LBA [ 0 .. lead-out ) range when we perform a track split. This is also true for data discs. If, as a result of mastering, there is non-zero data either in lead-in ( -inf .. 0 ) or lead-out [ lead-out .. +inf ), this is preserved in separate files. For discs with data tracks, non-zero data means the descrambled data portion of a sector (fields such as sync, MSF, mode, subheader, ECC/EDC is excluded). The resulting lead-in/lead-out files should be trimmed to the minimum non-zero data size, lead-in from the front and lead-out from the back, but they should remain sector-aligned (size divisible by 2352).

Considerations for matching Audio CD with different write offsets
For each disc, dumping software can generate a checksum/hash for the non-zero sample span of the data e.g. aligned to 4-byte CD sample size. Such hash can be used for the disc identification purpose as well as for Audio CD different write offset matching as for such cases the hash would be the same. This applies to both audio and data discs. I suggest to use a longer SHA-1 hash and not CRC32 just to be future proof. It's quite likely that we will get a couple of CRC32 collisions in ~100K discs currently in the DB. As a side perk, it can also serve as a unique disc ID which can be easily looked up in the database, if such capability will be ever implemented at redump.org. In any way, I would like to have such a hash in Audio CD entries just for write offset matching.

END OF EDIT, the rest information here is kept for the reference and archival purpose.




This topic is to clarify and decide on how we manage disc write offset for audio discs.

The current status quo is that we always dump audio discs with offset 0 as there is no reliable reference point in the audio stream (in contrary to a data track) which can be used to determine the offset. This approach has a number of disadvantages, such as:
* shifted audio data in pre-gap / lead-out which we don't currently preserve
* ocassional imperfect track split which cuts in the middle of audio tracks e.g. you hear a bit of the next track in the end of a current one or previous track in the beginning of the current one

I believe I solved both of these problems in redumper. Let me define some terminology first.
Perfect Audio Offset is a disc write offset which guarantees that no data is shifted into lead-out and guarantees track split which doesn't cut into a middle of a track.

Perfect Audio Offset implementation details
For a given audio disc, I build a silence map based on TOC/subchannel information, essentially it's INDEX 00 CUE entries which are almost always empty (silent). As a next step, I build a similar silence map based on an audio stream. Finally, For each offset within [-150 .. lead-out] constrained range, I try to line up these two maps in a way that TOC/subchannel based one fits into an audio stream. If it fits, it's a perfect audio offset.

The current audio offset logic
favor offset value from perfect offset range if available
if multiple perfect offset values available (range), try to shift data out of pre-gap (if needed) if still within a perfect range
otherwise if no data in pre-gap, favor offset 0 if it belongs to the perfect range
finally, if offset 0 doesn't belong to the perfect range, use a value closest to 0 within a perfect range
if no any perfect offset available, try to shift data out of lead-out and pre-gap (only if we can get rid of full pre-gap data) if that doesn't lead to data loss.

or pseudocode:

Code: Select all

if(perfect_audio_offset_available)
{
    if(perfect_offset_single_value)
        use_offset_value();
    else if(perfect_offset_value_range)
    {
        if(data_in_pregap)
        {
            if(enough_space_to_get_rid_of_whole_data_in_pregap AND still_within_perfect_range)
                move_minimum_data_right();
        }
        else if(zero_offset_belongs_to_perfect_range)
            use_zero_offset();
        else
            choose_the_offset_closest_to_zero();
    }
}
else
{
    if(data_in_leadout)
        move_minimum_data_left();
    else if(data_in_pregap AND enough_space_to_get_rid_of_whole_data_in_pregap)
        move_minimum_data_right();
}
Pre-Gap notes
Based from the discs I own and discs I have an access to, most audio discs with data in pre-gap is not a result of a write offset but rather a way it was mastered. It's often values close to silence but not zeroed and sometimes it's a part of a hidden track (HTOA). In cases like this, there is no way to move out that data fully out of pre-gap without it shifting into lead-out as there is not much space (it's common to have 1-2 seconds of pre-gap data audio which is a lot). I can definitely say it worth preserving by extending track 1 fixed 150 sectors back for all such cases, with, optionally, marking that in CUE? Before anyone says it's stupid, DIC already does a similar track 1 extend for CDi-Ready discs.

Statistics
With new method, I redumped all my audio discs and sadikyo redumped some of his. I shared new dumper version with Intothisworld and he shared it with ppltoast but I have yet to get some results from them. The current merged detail statistics is available here:
https://docs.google.com/spreadsheets/d/ … sp=sharing

TL;DR
73 discs - match redump (offset 0 is one of the perfect offsets)
9 discs - no perfect offset found (no distinctive silence in index 0 or no index 0 entries at all), offset 0 used so matches redump
7 discs - only one perfect offset found and it's true offset value used to master disc with, will require DB update
27 discs - perfect offset range excludes 0, will require DB update
3 discs - have pre-gap data which is impossible to fully shift out and it's not currently preserved, will require DB update

Side Effects
Given method works really well for PSX GameShark Update discs and Jaguar discs without relying on magic numbers and we get a perfect splits there too.

More Side Effects
If we left-align (or right-align) offset based on a perfect offset range, we will be getting matches for audio discs with the same data but different write offset, such as:
https://redump.info/disc/77301

I would like to hear your opinions on what do you think of it, let's discuss.

Re: audio offset

Posted: Sat Jul 02, 2022 5:36 am
by F1ReB4LL
superg wrote:This topic is to clarify and decide on how we manage disc write offset for audio discs.

The current status quo is that we always dump audio discs with offset 0 as there is no reliable reference point in the audio stream (in contrary to a data track) which can be used to determine the offset. This approach has a number of disadvantages, such as:
* shifted audio data in pre-gap / lead-out which we don't currently preserve
Wrong, dumpers must tweak the offset value to include all the data if possible, also DIC should do this automatically, IIRC. Sometimes both pregap and leadout have data, needs manual analysis in this case (usually it's about tweaking the offset to include the leadout data + extracting the pregap, like it's done in https://redump.info/disc/6695/, but I guess it depends on which of the pregap and the leadout portions of data is smaller - the smaller one needs the offset tweaking, the larger one needs the extraction).
superg wrote:* ocassional imperfect track split which cuts in the middle of audio tracks e.g. you hear a bit of the next track in the end of a current one or previous track in the beginning of the current one
There are thousands of games with the same problem, so it's mostly about their bad mastering rather than direct offset issues.
superg wrote:Perfect Audio Offset implementation details
For a given audio disc, I build a silence map based on TOC/subchannel information, essentially it's INDEX 00 CUE entries which are almost always empty (silent). As a next step, I build a similar silence map based on an audio stream. Finally, For each offset within [-150 .. lead-out] constrained range, I try to line up these two maps in a way that TOC/subchannel based one fits into an audio stream. If it fits, it's a perfect audio offset.
Crazy. I think that matching EAC and AccurateRip databases for the 'offset 0' audio tracks is a better benefit compared to some custom aligning. Also, what happens if all the tracks have big portions of silence at their beginnings and endings? Does it shift the offset to force the first track to start from its first nonzero byte?
superg wrote:Side Effects
Given method works really well for PSX GameShark Update discs and Jaguar discs without relying on magic numbers and we get a perfect splits there too.
It will NOT work for Jaguar discs at all, because its 'data' (the INDEX 01 of the second track of the second session) must start with its magic (according to the official Jaguar CD format description documents), but if you align according to the magic, the first track of the first session for a good half of Jaguar CD releases gets shifted to the first pregap - and in your case, if you align according to the non-zero data and silences, its magic will be way off its proper position.

Re: audio offset

Posted: Sat Jul 02, 2022 7:19 am
by superg
Jackal wrote:The logic as described sounds good to me. I'm assuming the offset correction is always in samples, so a multiple of 4 bytes?
Yes, I analyze it as multiples of 4 bytes (two signed 16-bit sample values).
Jackal wrote:I would also like to know if your method is able to find the true "perfect" offset for discs such as these: https://redump.info/discs/quicksearch/wri … /audio-cd/ + https://redump.info/discs/quicksearch/det … region/Eu/ where aligning either left or right to the first byte gives a "common" write offset value that is consistent with the ringcode.
Don't have any from this list unfortunately, you can try redumper if you have any of these, for each audio disc it will output something like

Code: Select all

detecting offset
audio silence detection... done
perfect audio offset (silence level: 5): [+736 .. +22675]
disc write offset: +736
warning: pre-gap audio contains non-zero data, preserving (session: 1, leading zeroes: 87473, non-zeroes: 727/88200)
detection complete (time: 75s)
And after that "redumper split --force-offset=22675 --overwrite" to align it.
Jackal wrote:Maybe this should be an extra step? So validate for common offset values when shifted to first or last non-zero byte before going with 0 offset or whatever else the logic would decide on. Would be great if you could test that using some of the images.
I also thought about something like this. Left shift (or right shift) to the first non zero byte and calculate some hash and use it as a universal checksum which allows us to match same audio discs mastered with a different offset. For instance for two such discs from here: https://redump.info/disc/77301, if I right-align, both dumps match.

Re: audio offset

Posted: Sat Jul 02, 2022 7:41 am
by superg
F1ReB4LL wrote:Wrong, dumpers must tweak the offset value to include all the data if possible, also DIC should do this automatically, IIRC.
True, we want dumpers to do that, but the status quo is that they really don't. They do whatever DIC does by default.
F1ReB4LL wrote:Sometimes both pregap and leadout have data, needs manual analysis in this case (usually it's about tweaking the offset to include the leadout data + extracting the pregap, like it's done in https://redump.info/disc/6695/, but I guess it depends on which of the pregap and the leadout portions of data is smaller - the smaller one needs the offset tweaking, the larger one needs the extraction).
Even if we separately extract pregap.bin, it can be automated. I don't necessarily like this approach as pregap data usually belongs to track 1. It's fine if it's "almost silence" but Intothisworld owns a disc where it's HTOA in there.
F1ReB4LL wrote:There are thousands of games with the same problem, so it's mostly about their bad mastering rather than direct offset issues.
True, but at least we have a way for them to determine a proper offset value using data track.
F1ReB4LL wrote:Crazy. I think that matching EAC and AccurateRip databases for the 'offset 0' audio tracks is a better benefit compared to some custom aligning.
We can still have hashes or some other info calculated for offset 0 to satisfy the compatibility things like EAC/AccurateRip.
F1ReB4LL wrote:Also, what happens if all the tracks have big portions of silence at their beginnings and endings? Does it shift the offset to force the first track to start from its first nonzero byte?
No no, it's not like that. The current logic doesn't align to first non-zero sample. I calculate perfect offset range, but if offset 0 belongs to that range, it's has a higher priority. The disc you describle with the big portion of zeroes at the beginning and end will have a big slack which will most likely include offset 0.
F1ReB4LL wrote:It will NOT work for Jaguar discs at all, because its 'data' (the INDEX 01 of the second track of the second session) must start with its magic (according to the official Jaguar CD format description documents), but if you align according to the magic, the first track of the first session for a good half of Jaguar CD releases gets shifted to the first pregap - and in your case, if you align according to the non-zero data and silences, its magic will be way off its proper position.
It works for the Myst Demo I own. I can't speak for the generic case. My Myst Demo aligns to that magic using the logic I described:

Code: Select all

detecting offset
audio silence detection... done
perfect audio offset (silence level: 0): [-2201 .. -401]
disc write offset: -401
warning: pre-gap audio is incomplete (session: 2, errors: 371)
detection complete (time: 14s)
As offset 0 is not included in the perfect range here, -401 is closest to 0 so it gets chosen and that perfectly coincides with aligned by magic.
By default I have it implemented using magic, like DIC does. I just remember you mentioned you're not fond of the current way so if you think we can do something better for Jaguar CD - let me know.

But the algo is still useful for PSXGS as if you align by magic, it cuts through other data portions.

Re: audio offset

Posted: Sat Jul 02, 2022 7:46 am
by superg
Jackal wrote:So my question for this discussion is:
Do we really need a "perfect offset" correction if there is no data loss with 0 offset (and no common write offset can be detected)? After all, we wont know how the disc was mastered and if the gaps are supposed to be silent.
Yeah, this is legit question, if no data is lost, we just end up with imperfect split sometimes. But that technically can be corrected just from BINs if needed.

Re: audio offset

Posted: Fri Jul 15, 2022 4:10 pm
by superg
Ok, so some cool down period passed, let's regroup.

Let's say, we remove perfect track split out of consideration. I'll have redumper output perfect audio offset range anyway just for reference but will not apply it by default. The concept would be super useful for perfectionist audio folks so I'm happy I have that implementation for them.

What's basically left for us @redump is to define a clear approach to how we handle audio discs with non zero pre-gap and lead-out data.

I guess we have a consensus on the next two rules:
1. if there is non zero data in lead-out and that data can be fully shifted out of there (left) without spanning non zero data into pre-gap, correct offset with a minimum shift required
2. if there is non zero data in pre-gap and that data can be fully shifted out of there (right) without spanning non zero data into lead-out, correct offset with a minimum shift required


How to define situations where it's impossible to shift out data from lead-out/pre-gap (data is wider than allocated TOC space for it), several options:
1. Use offset 0 as a base, dump non zero pre-gap data to pregap.bin, dump non zero lead-out data to leadout.bin
2. Fully shift data out of lead-out if needed, dump non zero pre-gap data to pregap.bin
3. Use offset 0 as a base, prepend non zero pre-gap data to the first track, append non zero data to the last track
4. Fully shift data out of lead-out if needed, prepend non zero pre-gap data to the first track


My insight:
I don't like(1) or (2) because preserving data to external pregap.bin and leadout.bin files will usually be "lost" because it's unreferenced from the CUE-sheet and I don't see a good way of linking the files to the other cue/bin set.
I also don't like (1) or (2) because in all cases that I saw, non zero pre-gap data genuinely belongs to the first track. It's either HTOA index 0 entry or non zeroed mastering "silence" which is still part of the first track.
Lastly, I didn't find a proof anywhere in the Red Book standard that pre-gap data of an audio disc should be zeroed. I found such a requirement only for the pre-gap of a data track in ECMA-130.

That said, I personally would lean towards (4).

Let me know what do you think.

Re: audio offset

Posted: Fri Jul 15, 2022 4:56 pm
by superg
Jackal wrote:And where does this discussion leave us with discs like those PSX with audio in lead-out? I'm against appending lead-out data to the last track, because it's just not part of the main tracks. Also, I dont think we should shift audio data out of the lead-out for mixed mode discs, because the combined offset correction overrules it. So the only solutions for such discs imho is to put the data in leadout.bin or do nothing with it.
I totally agree with that. I purposely haven't mentioned that yet to get Fireball's opinion on pregap.bin/leadout.bin and focus on one issue at a time Image.
In all situation where we have an offset determined by a data track, we shouldn't extend last track, saving leadout separately for cases like this would be possibly a best solution?
TL;DR, shifting data out of lead-out / pre-gap should happen only for the discs where we can't figure out an offset in a deterministic way (based on data track sync/MSF or anything similar).

Re: audio offset

Posted: Wed Jul 20, 2022 11:45 am
by sadikyo
I can share that at least conceptually, I definitely agree with superg's general direction and what he is trying to accomplish here with a solution for the audio cds.

As for some of the specific concerns raised, some of it is a bit outside the scope of my technical knowledge, so it's hard for me to provide valuable input.

I'm very curious to hear what fireball has to say about the recent discussion.  I do think that discussing and addressing this before too long, is pretty important.  As someone else said as well, I know some people are holding back on preserving / submitting audio discs, because they know there are pending issues that need fixing.

Thanks to all of you for your amazing work on this, and especially superg, for digging deep into these issues and bringing this to the forefront.

Re: audio offset

Posted: Fri Aug 19, 2022 1:58 pm
by sadikyo
Just checking to see if there are any thoughts, concerns, updates about the audio cd issue? I know this took a bit of a back-burner due to the site concerns, of course.

Do we have any sort of consensus on how to proceed here?

Re: audio offset

Posted: Fri Aug 19, 2022 2:18 pm
by superg
I want to try some CD's suggested by Fireball to see if we're covered there.