--- Preamble ---
The technical analysis below was generated by Claude (Anthropic's AI
assistant), working from raw disc data I provided over an extended
back-and-forth investigation. I'm including it as-is since I believe
the findings are sound and independently verified against a
known-correct reference decode, but I want to be upfront that an AI,
not me, did the reverse-engineering. My own note follows at the end.
--- Start of AI Generated Analysis ---
Hi,
pcm_dvda correctly identifies this DVD-Audio disc as using split channel
groups at different sample rates, and correctly declines to guess at a
decode rather than produce wrong output:
[pcm_dvda] Mixed group sample rates (96000, 48000) is not implemented.
I've spent a while reverse-engineering this specific disc against a
known-correct reference decode (foobar2000, via its DVDADecoder plugin,
which does handle this case) and have a reasonably complete picture of
the container-level structure, but not the intra-frame sample layout.
Sharing what's confirmed in case it's useful, and asking whether the
project has (or would want) a sample of this format.
Disc: commercial DVD-Audio release, authored with Cirlinca HD-Audio Solo
Ultra (confirmed via the UDF ImplementationId field, "*CLN::DOS"). Happy
to upload the ISO or just the relevant AOB file(s) to
streams.videolan.org if useful - it's ~2.7GB total, or I can extract a
smaller isolated sample if that's more practical.
## What's confirmed
All of the below was verified against the disc's own declared fields
(not assumed), and cross-checked against a byte-perfect reference decode
(foobar2000) sample-for-sample, not by correlation/similarity.
- LPCM substream header (private_stream_1, substream_id 0xA0) declares:
- sample_size byte 0x22: both nibbles = 2 -> 24-bit for both groups
(per the documented 0=16bit/1=20bit/2=24bit scale)
- sample_rate byte 0x10: high nibble 1 = 96kHz (group 1), low nibble 0
= 48kHz (group 2)
- channel_group_assignment = 12 (decimal) -> L, R, C, LFE, Ls, Rs, per
the documented assignment table - confirmed against what a reference
decode shows in Audacity (Left Front, Right Front, Center, LFE, Left
Rear, Right Rear, in that order)
- header_length (substream offset +2..+3) is a genuine 2-byte field, not
a single byte - the high byte is 0 on every pack on this disc, so a
1-byte read happens to give the same numeric result here, but isn't
correct in general.
- byte_pointer (substream offset +4..+5) is a genuine 2-byte field
giving the offset, within this pack's audio payload, of the first
frame-aligned byte - i.e. how many bytes of this pack's payload belong
to completing a frame that started in the previous pack. Confirmed to
be 1-indexed (points to "the Nth byte", not a 0-indexed offset) -
determined empirically by finding the byte count that makes every
subsequent pack's declared byte_pointer match a predicted value
exactly.
- Frame size is exactly 960 bytes: 480 bytes for the two 96kHz channels
+ 480 bytes for the four 48kHz channels, both at 24-bit
(2*96000*3 + 4*48000*3, over the frame's common 80/40-sample time
window). This isn't inferred from the byte-rate alone - it's proven
arithmetically: byte_pointer decrements by exactly 48 (= 1968 mod 960,
where 1968 is this disc's typical per-pack audio payload size) on
every single one of 10,740 consecutive packs across the first track,
zero exceptions, including correct wraparound at the 960-byte
boundary. A 27-byte or 20-byte frame (both considered and ruled out
below) would predict a different, and wrong, decrement.
- The two 96kHz channels are channels 1 and 2 in the
channel_group_assignment
order (i.e. the first two channels declared, matching L/R) - confirmed
via the disc's own measured total byte rate matching a 2ch@96kHz +
4ch@48kHz split, not the reverse.
## What's not resolved: the intra-frame sample layout
Given the above, each 960-byte frame is known to split into a 480-byte
half for the two 96kHz channels (80 samples/channel) and a 480-byte half
for the four 48kHz channels (40 samples/channel), in one order or the
other. What hasn't been determined is how samples are packed to bytes
within each half.
Tested, all via exact sample-for-sample comparison against the
reference decode (not correlation or partial matching), on the first
sector of the first track - chosen specifically because the disc's true
start guarantees an unambiguous WAV-sample alignment with no
accumulated/derived offset in the way:
1. Four named byte layouts within the confirmed 480+480 structure, each
an extension of the "MSB+mid pairs, then all LSBs" style already
verified correct for this format's ordinary (non-split-group,
single-rate) LPCM case:
- channel-interleaved pairs, LSBs deferred to end of group
- channel-blocked pairs, LSBs deferred to end of group
- fully planar, channel-interleaved (all MSBs, then all mids, then
all LSBs)
- fully planar, channel-blocked
Each tested with both possible group orderings (96kHz half first or
48kHz half first) - 8 total combinations. All fail at or within the
first few samples on every channel.
2. A separate structural hypothesis (3 channels @ 96kHz + 3 channels @
48kHz rather than 2+4, in 27-byte blocks, straight big-endian 3-byte
samples, no bit/nibble splitting) - considered because it's what a
second LLM proposed when given the same raw bytes; testing it
directly seemed more useful than debating it. It also fails
immediately - and is independently inconsistent with the disc's own
byte_pointer arithmetic above, which requires a 960-byte frame, not
27.
Happy to share the small validator tool (a self-contained C# console
app) that produced these results if it's useful for reproducing them,
along with the specific sector 0 byte dump and the matching reference
WAV excerpt.
## Ask
Is there a documented (or tribal-knowledge) description of the
intra-frame byte layout for split sample-rate/bit-depth LPCM groups on
DVD-Audio? Everything above was derived from the disc's own declared
header fields plus exhaustive testing against a reference decode; the
one piece we don't have is an authoritative description of the sample
packing itself, which is presumably needed to implement this in
pcm_dvda. Happy to help test against additional discs/samples if that's
useful.
--- End of AI Generated Analysis ---
I have been attempting to use AI tools to decode DVD ISOs to extract all audio
(no video) data, and have successfully managed to get it to decode most of
the ISO files I have thrown at it, including most DVDA and DVDV files.
Originally,
this was done by simple scripting, calling command line utilities such as
ffmpeg to do the actual extraction. However, I have one ISO (so far) with
mixed audio rates that so far has defied extraction with any command line
tool I have pointed at it. The data extracted so far has at best been static
with the actual audio somewhat discernable beneath the static.
I make no claim to understand the data format beyond what I have read on
various web pages, hence asking AI to help with this. The project started
out as a simple script to detect the ISO format then call the proper
command line tool to extract the audio, originally only ffmpeg, later also
attempting to use dvda-author and a few others. This is when I found no
tool quite handles all formats properly, and got into trying extracting the
PCM data from the VOB files directly using the C# compiler that comes with
Windows (MLP data is still extracted via ffmpeg), and this led to the
discovery that the 96Khs/48Khz mixed format isn't really handled by any
command line tool. The AI tool works well for pretty much everything else
I have tried but this. Of all of the other tools I have tried, only
foobar2000 with the dvda decoder works, others produce either silence (VLC,
31 hours of
it), or the same sort of static with underlying audio (Lossless Extract),
or crashes (dvda-author).
I don't know if the output of this AI will prove useful in any way, but if
so, I offer the information to you. If not, or it is not the sort of thing
you want to make use of for philosophical reasons (totally understandable),
then I can at least provide any data samples that you may need.
Thanks,
Jeff Wormsley
_______________________________________________
ffmpeg-devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
