Muxman - 24/96 PCM audio

[insane822]

I've tried loading a 24-Bit / 96kHz 2-CH PCM that was captured with ppcmripper, muxman gives me an error saying "LPCM quantization not allowed".

mpucoder, in the other thread you said that you'd need to see the header ( everything from 'RIFF' to 'data'). Where might I find this information?

[mpucoder]

If you have a hex editor you can see this information in the first 36 bytes, usually. If the file isn't too big (like under 50M) you could send the whole thing to me.

[insane822]

Is this the part you need? Thanks :)

[mpucoder]

I was just looking at the code and spotted an error. It only affects 96K. I'll have a fix for 0.15 up as soon as I can test it and make sure there is no other problem with the header you attached.

[insane822]

Thanks

I guess I'll have to try and donate ;)

[mpucoder]

I'll add this fix to 0.14 as well, it will just be a little later as the full test takes about an hour.

[mpucoder]

0.14g is available now from the MuxMan homepage (http://www.mpucoder.com/Muxman/)
It fixes this problem.

[insane822]

0.14g is available now from the MuxMan homepage (http://www.mpucoder.com/Muxman/)
It fixes this problem.


Thanks a million for your work :)

[drmih]

Does anyone know of a programme which will do the same for the 6 multi-channels produced by ppcmripper without having to drop the frequency?

[mpucoder]

I'm not sure what you mean by "do the same" - the limit on channels imposed by MuxMan is the DVD spec limit. It is not possible to get 6 channels of 24/96 onto a DVD, that would require a bitrate of 6x2.304 = 13.824Mbps. The maximum for a DVD is 10.08, and for PCM audio is 6.144

[drmih]

Yes but it'd be nice to override this as I've found that dvd-videos created on something like dvd author, where you can exceed the limit (of the video / audio combination) but with a warning seem to play okay on every player I've tried them on. I just wondered, now that wav files can be extracted from dvd-audio discs, whether you could just author them unaltered with a single bitmap and see if they played.

[mpucoder]

There are 2 constraints, the DVD spec for PCM audio and the system mux rate (10.08Mbps). The first is an arbitrary number and could be overriden to get you 4 channels (4x2.304 = 9.216), with very low bitrate video/stills. But the second constraint cannot be exceeded.
Muxman and DVD Author can proceed with the mux even if the combined stated bitrates exceed the spec maximum. Multiplexers can do this because the stated video bitrate is usually incorrect, and at best represents the peak bitrate. I've seen peaks as high as 14Mbps get multiplexed properly due to buffering. But the average bitrate of such a multiplex, even for the short term of 500ms, is below 10.08 or the mux would fail (Muxman states excesive bitrate, mplex, the multiplexer used by DVD Author, says data will arrive too late.)
But this is for variable bitrate video. LPCM is constant bitrate, so there is no bitrate headroom.

[drmih]

I'm confused now - this is what it says on DTSONLINE:

"What is 96/24?

More recording is being done at a 96kHz sampling rate and at 24 bits. DTS has always had 24-bit capability, and DTS 96/24 adds the 96kHz capability. It is fully compatible with existing DTS decoders, which will output 96/24 tracks at 48kHz. DTS 96/24 is the only commercially-available system that:

*provides 5.1 channels of 96/24 along with full-motion video on DVD-Video and DVD-Audio (video zone),
*is compatible with all DVD-Video players, and
*is accessible through the digital output.

The DTS coding system has a “core + extension” structure. The “core” represents the DTS data as has been known since the first home decoders. The “extension” can carry data for future applications or enhancements of any sort. All DTS decoders recognize and use the core data. Basic decoders ignore the extension data, while advanced decoders can make use of it. This allows for full backward compatibility for any scheme using the extension. DTS has recently used the extension field for two purposes. In the first case, it has been used to carry an additional channel for 6.1 dis-crete. In the second case, the extension field carries the additional spectral data added by 96-kHz sampling. For a program in DTS 96/24, existing decoders read the core at 48-kHz and reproduce the standard spectrum. DTS 96/24 decoders read both core and extension and reproduce the extended spectrum. The data rate for 96/24 is 1.536Mbit/s, the higher of the two DTS rates presently used. While numerically this might suggest twice as much compression, there is in fact negligible additional compres-sion on the core data. This is because there is relatively little information in the range 24-48kHz, so it can be coded very compactly. The 96/24 stream passes through the S/PDIF just as standard DTS does. "

[mpucoder]

But this thread is about PCM, not DTS. DTS uses lower bitrates (it is a compressed format) and can carry as many channels as the designers of DTS can fit into their allotted 1.536Mbps maximum bitrate.
It was my understanding, from the very first post, that ppcmripper captures the decoded (LPCM) audio in riff (.wav) format. DTS, LPCM, AC3, and maybe others can all encode from and decode to 24/96 audio. 24/96 (or 96/24) refers to the quantization (number of bits per sample) and sample rate of the original or reproduced audio. But the format used to represent that data determines the bitrate required.

[drmih]

Okay, so to have a true lossless multi-channel dvd-video, using the LPCM audio extracted from a dvd-audio, would require a bitrate size far in access of that allowed. To go to the highest quality multi-channel dvd-video possible, you'd need to take the 96/24 wav files and encode them to DTS 96/24 - I think that only the Pro Series DTS encoder can do this. Otherwise, you need to drop the frequency of the original wav files to 48/24 and then either encode as Dolby or DTS as 48/24?

[mpucoder]

Yes, preferably DTS.

[aval57]

mpucoder, this is almost exactly what I was waiting for. big thanks!!!

One question, though:

I authored a single song "audio dvd-v" (bitmap video + 24/96 LPCM audio) using muxman, then demuxed the audio back to wav (using PgcDemux first, then again using vstrip + lpcm24 to double-check). Either way, the reconstituted wav data appears to be an identical but slightly truncated copy of the source data.

Any idea why this is? It would be ideal to be able to use muxman for archiving lpcm audio on playable DVDs, so long as the process is lossless and the identical data can be re-extracted in full as needed.

Also, is there a way to add an "extras" directory to the dvd structure to store misc archival information such as md5 files, setlists, artwork etc?

[mpucoder]

If the demuxed file was no more than 960 bytes shorter then I can explain it. For 24/96 the audio frame size is 960 bytes (on DVD LPCM uses 600fps, so 576000 / 600 = 960). If a still is held for "audio duration" the duration is calculated for whole audio frames. Enough video frames are then used to multiplex all the whole audio frames. If enough time is left at the end the last partial frame will be muxed, but there is no guarantee.
If you set the video duration to at least one frame longer than it currently is all the audio should be there.
But I should change the calculation to round up one audio frame to guarantee that the last partial frame is muxed. Which version (0.14 or 0.15) are you using?

In answer to your second question, you can create another folder off the root of the DVD for extra files, most burning programs will allocate the space correctly so as not to interfere with DVD-Video.

[aval57]

Absolutely right - less than 960 bytes shorter, and I'm using v0.14 :-)

I can see that still duration can be reset from 'actual' to 'audio end' (and controlled fully in mxp too); and I'm guessing control over audio duration may be available in v0.15, since reset appears to have no effect here (and no duration setting in mxp either). Would the poor man's only solution be to pad the input file?

Is this analogous to sector boundary alignment in cd audio? i.e. must tracks be cut at multiples of 960 to avoid gaps in continuity during playback?

[mpucoder]

It is more because only LPCM can have partial frames. All the other formats are compressed and have real frames of data, whereas LPCM frames only exist in the "mind" of DVD software. So the logic was optimized for the compressed formats to work in frames. There is also the consideration of what happens when 2 or more LPCM files are used in one segment.

If you are using a still, either a single frame m2v or a bmp, you can set any duration you like. Open the multifile manager, click on the still, then set the time dials to whatever value you want and then click "set".
You can use many programs to see what the old mux's time was, I used IfoEdit just now to confirm this method. Just increase that time by 1 frame and the entire audio will be multiplexed. You may still see a small difference as the DVD format requires an even number of samples. My test case worked out perfectly.

I know this is a clumsy workaround, and when I develop a fix (in the new 0.16) it will be retrofitted to 0.15 as well.

[aval57]

Thanks for all the support mpucoder!

I tested an input file with an exact multiple of 960 data bytes, which demuxed back to full data plus some null bytes (44+22905600 -> 44+22905600+280); is this approach reliable?

This would be a better workaround for me, since it would allow automation; i.e. batch resizing/recutting and then muxing via an mxp file. Also, would the chapter file look like this:

0
23860
443792
...etc (absolute coordinate of each start frame?)

[mpucoder]

I don't know where the null bytes came from, maybe the demux program.
There are a couple reasons not to use chapters as they are in 0.14 to divide songs. First each chapter must have a new still image. MuxMan neither creates a new image for you (ie repeat the last) or gives an error. While you can play a DVD like this, seeking by chapter does various things depending on the player (it may freeze, show the first image, show a blank screen, stutter, etc).
The second problem is that the audio of one segment, which is all 0.14 can create, has no pauses in it. This means you cannot align the second and later songs to a video frame, making it difficult to determine where the chapter point should be. Individual segments work better for this, as each new non-seamless segment is a sync point.
This doesn't mean it can't be done, you just have to remember to add another still for each chapter (it can be the same file), and make its duration the same as the chapter duration. Duration times are non drop, meaning that 1 NTSC second is always 30 frames (1 PAL second is 25 frames). BUT - that is just the timecodes, the video does run at 29.97fps, so you have to factor that in if you are converting the audio duration to video frames. A simplified version of the revised formula going into 0.15 for 24/96 2ch is:
NTSC_video_frames = (((audio_data_size * 5) / 32) + 3002) / 3003
That uses integer math all the way. The 5/32 is simplified from 90000/576000, 90000 is the number of clock ticks in one second, 576000 is the number of data bytes in one second. 3003 is the duration in clock ticks of an NTSC video frame, and 3002 is for rounding up.

If you are going to use an mxp file, do not use a chapter file. Use scenes.