DVD, DVDA and Blu-Ray Audio Samples Specification Differences

[Nexin]

DVD, DVDA and Blu-Ray Audio Samples Specification

Seeing many DVD and DVDA audio discs authored incorrectly. In been that each track doesn't start exactly where it should. For DVD audio discs the A/V is reported by PGCDemux etc as 0 zero. With playing and extract can tell they are not 0 zero.

Q1. Is there any tools to show the A/V offset for DVDA and Blu-Ray Titles ?


CD Redbook specification shows 1/75 (588 stereo samples) for 16bit/44.100kHz.

Q2. Does the DVD, DVDA and Blu-Ray specification also share the same specification as CD. Even though DVD and DVDA more often has greater bit/kHz and multi channel audio such as 48bit/96000kHz (5.1 audio) ?

Q3. What is the DVD, DVDA and Blu-Ray specification is for sec/frames samples ?

[Emulgator]

A1: Blu-ray: Some muxer will show on demuxing.
DVD-A: I don't know, foobar with DVD-A plugin?

A2: No. The time granularity of CD-DA data is only available because a fixed audio bitrate allows that.
One CD data block is 2352 Byte, and this can be called an audio frame because of a fixed size structure:
One of these frame consists of 98 small frames, 33 bytes each.
6 stereo audio samples of 4 bytes each fit into here, giving 24 audio bytes, plus 8 byte Error correction, plus 1 byte subchannel.
6 samples * 98 = 588 samples. 588 * 1/44100 = 1/75 s. There you go.

DVD-Video allows variable bitrates for video and many constant bitrates for audio.
Two streams with differing bitrates do not allow timeline navigation by memory block's distances anymore.
These streams have to be muxed into a container which provides timeline access by introducing timestamps.
Now any audio-dictated granularity is gone, timestamps prevail and video framerates prevail anyway.

For DVD-Video 90.000 ticks per second were specified. A 27MHz quartz delivers the timebase.
Divided by 300 yields 90.000 ticks per second. Fine enough for all tasks.
Divided by 3003 we get 29.97fps, the NTSC framerate, divided by 3600 we get 25.000 fps, the PAL framerate.
The .VOB container of DVD-Video delivers this. A 33bit counter is needed to cover 24 hrs of timestamp value.

For .AOB of DVD-Audio two main sample rates 44.100/48.000
and their derivatives 2*fs 88.200/96.000/and 4*fs 176.400/192.000 have to be accommodated as well.
The existence of MLP leaves us with a varying bitrate again, not being able to deduct time from blocks.

Blu-ray accommodates even more combinations of streams with varying bitrates.
Blu-ray muxers have to pass 32-bit (4byte) timestamps with 45.000 ticks per second into a special MPEG-2 transportstream
with an extended packet size of 192 byte (normally 188 byte). The additional 4 bytes are made up of this 32-bit timestamp counter.
I guess 45.000 tps were chosen mainly to have only 32-bit, so 4byte timestamp counters possible to cover 24hrs of timestamp value needed for broadcast
After all the TS container overhead is huge compared to .VOB, we do not want open up another byte using only one bit, do we ?

A3: There is no such "audio frame" anymore.
The containers .VOB, .AOB, .m2ts dictate time navigation by ticks
and the muxers have to deliver pre-calculated-while-muxing block offset addresses into the muxing result.
These offsets are needed by the playing application to jump certain times ahead/back -> FFWD/REW.

You have wondered about audio offsets on a muxed product.
Audio offsets are used because the container made it possible.
On authoring stage somebody might notice a necessary offset between the delivered A/V streams
and quickly solves that by specifying a muxing offset. That's all.
Takes less time than rendering some frames of black onto TBytes of preciously prepared masters before the movie start
or rendering silence at the start or end of GBytes of multichannel audio streams passed on by people that did not see the result before.
The player follows that mux like a slave, so the existence of audio offsets is not necessarily a fault.
Only wrong when not leading to synced presentation.
One got to take care of it and when you want to work on that mux a second time, demux and remux:
You got to take good care as well, that's all.

[Nexin]

I always did wonder the differences were between them. With your detailed guide we now know the differences.

Which I have also copied for future reference. :)


Found this using terms you wrote above http://dvd-audio.sourceforge.net/spec/index.shtml