Mux/Demux WAV/W64 files in MKV container

[tebasuna51]

MkvToolNix (MkvMerge and MkvExtract) have some troubles with certain WAV/W64 audio data. Read my post in MkvToolNix thread (https://forum.doom9.org/showthread.php?p=1966534#post1966534).

Like seems the MKVToolNix author don't want solve (https://forum.doom9.org/showthread.php?p=1966558#post1966558) that troubles I want say you the workarounds than can be used.

1) ffmpeg can mux WAV files with wformat <> 0xfffe (WAVE_FORMAT_EXTENSIBLE header). Can demux all WAV formats.

That solve the issue 2757 of MkvToolNix (https://gitlab.com/mbunkus/mkvtoolnix/-/issues/2757).

I create a ticket in trac.ffmpeg.org (https://trac.ffmpeg.org/ticket/9703) asking for support mux wformat = 0xfffe also.

MkvMerge only support mux WAV files with wformat 1 (int) or 3 (float).
MkvExtract only support extract WAV files with wformat 1 (int).

2) The old (2010) AVI-Mux GUI (https://www.alexander-noe.com/video/amg/) can mux WAV files in mkv with wformat 0xfffe and can be used until ffmpeg modify the behaviour.

[filler56789]

I wish that at least the DirectShow Matroska Muxer from MPC-BE's standalone filters package was updated to support 0xfffe WAV files integrally.
Also, it's saddening that the Matroska project is nearly 20 years old but it still hasn't found /created a "native method" to deal with multichannel uncompressed audio correctly.

[tebasuna51]

I wish that at least the DirectShow Matroska Muxer from MPC-BE's standalone filters package was updated to support 0xfffe WAV files integrally.

I test mpc-be last 1.6.2.6983 alpha and seems play correctly:
wfortmatTag 0x0002 ADPCM MS 2 channels 4 bits
wfortmatTag 0x0006 ADPCM A-Law CCITT 2 channels 8 bits
wfortmatTag 0x0007 ADPCM U-Law CCITT 2 channels 8 bits
wfortmatTag 0x0011 ADPCM Intel 2 channels 4 bits
wfortmatTag 0x0031 GSM 6.10 Microsoft 1 channel
wfortmatTag 0xfffe WAVE_FORMAT_EXTENSIBLE (some multichannel only tested)

I don't have ATRAC3plus and ATRAC9 samples to test.[EDIT] tested ok that sample (https://forum.doom9.org/showthread.php?p=1966710#post1966710).

And I was wrong about the support, by internal LAV_FILTERS in mpc-hc 1.9.20.24 (LAV Audio Decoder 0.76.1), of wfortmatTag 0xfffe WAVE_FORMAT_EXTENSIBLE.

You can see how read each player a 4 channel WAV:
WAVEFORMATEX: by MPC-BE WAVEFORMATEX: by MPC-HC
wFormatTag: 0xfffe wFormatTag: 0x0001
nChannels: 4 nChannels: 4
nSamplesPerSec: 48000 nSamplesPerSec: 48000
nAvgBytesPerSec: 384000 nAvgBytesPerSec: 384000
nBlockAlign: 8 nBlockAlign: 8
wBitsPerSample: 16 wBitsPerSample: 16
cbSize: 22 (extra bytes) cbSize: 22 (extra bytes)

WAVEFORMATEXTENSIBLE: pbFormat:
wValidBitsPerSample: 16 0000: 00 00 01 00 01 00 04 00 80 bb 00 00 00 dc 05 00 ........?»...Ü..
dwChannelMask: 0x00000603 0010: 08 00 10 00 16 00 10 00|03 06 00 00 01 00 00 00 ................
SubFormat: {00000001-0000-0010-8000-00AA00389B71} 0020: 00 00 10 00 80 00 00 aa 00 38 9b 71 fb 7f ....?..ª.8?qû

MPC-BE read the channelmask 0x0603 (L R Ls Rs) and play it correctly.
MPC-HC ignore the channelmask (inside the data showed like pbFormat) and show and play it like L R C LFE
VirtualDub2 play correctly the mkv.

Also, it's saddening that the Matroska project is nearly 20 years old but it still hasn't found /created a "native method" to deal with multichannel uncompressed audio correctly.

Really, I don't know the reasons of Mosu to don't want support that old WAV multichannel format.

Maybe there are problems more with some players or SO's (Unix, etc).

This is a little sample with two audio tracks, the first one is L R C LFE and the second L R Ls Rs, like MediaInfo can show correctly but MPC-HC play wrong (the audio is not in sync with video but this is not the problem): https://www.mediafire.com/file/0j1pzdjyvu6u48p/4c_testS.7z/file

[filler56789]

.............

This is a little sample with two audio tracks, the first one is L R C LFE and the second L R Ls Rs, like MediaInfo can show correctly but MPC-HC play wrong (the audio is not in sync with video but this is not the problem): https://www.mediafire.com/file/0j1pzdjyvu6u48p/4c_testS.7z/file

With MPC-HC I could not detect the problem, because apparently ffdshow's audio processor ""corrects"" it somehow :confused:, but with GraphStudioNext I noticed it. There is a bug (or a regression???) in LAV's Audio decoder... If you connect LAV Splitter directly to the Default DirectSound Device filter, then the second audio track is played correctly.

[tebasuna51]

I try GraphStudioNext but I don't have ffdshow filters installed but a old version (0.74.1.0, 19/Mar/2019) of LAV-Filters and the problem is the same (it is not a regression).

With the second track:
SubchunkID ..: fmt (Length: 40)
AudioFormat .: 65534 (WAVE_FORMAT_EXTENSIBLE)
NumChannels .: 4
SampleRate ..: 48000
ByteRate ....: 384000
BlockAlign ..: 8
BitsPerSample: 16
ValidBitsPS .: 16
MaskChannels : 1539 (FL FR SL SR)
SubType .....: 1 (Integer)

The LAV Audio Decoder show as output:
WAVEFORMATEX:
wFormatTag: 0xfffe (65534)
nChannels: 4
nSamplesPerSec: 48000
nAvgBytesPerSec: 384000
nBlockAlign: 8
wBitsPersample: 16
cbSize: 22
wValidBitsPerSample 16
dwChannelMask 15 [wrong is 1539 (FL FR SL SR)]
SubFormat MEDIASUBTYPE_PCM {00000001-0000-0010-8000-00AA00389B71}

All is correct except the ChannelMask. Seems is assigned by default, instead read, with source (media.cpp):
static const scmap_t m_scmap_default[] = {
// FL FR FC LFe BL BR FLC FRC
{1, 0}, // Mono M1, 0
{2, 0}, // Stereo FL, FR
{3, SPEAKER_FRONT_LEFT|SPEAKER_FRONT_RIGHT|SPEAKER_FRONT_CENTER}, // 3/0 FL, FR, FC
{4, SPEAKER_FRONT_LEFT|SPEAKER_FRONT_RIGHT|SPEAKER_FRONT_CENTER|SPEAKER_LOW_FREQUENCY}, // 3/1 FL, FR, FC, Surround
{5, SPEAKER_FRONT_LEFT|SPEAKER_FRONT_RIGHT|SPEAKER_FRONT_CENTER|SPEAKER_BACK_LEFT|SPEAKER_BACK_RIGHT}, // 3/2 FL, FR, FC, BL, BR
{6, SPEAKER_FRONT_LEFT|SPEAKER_FRONT_RIGHT|SPEAKER_FRONT_CENTER|SPEAKER_LOW_FREQUENCY|SPEAKER_SIDE_LEFT|SPEAKER_SIDE_RIGHT}, // 3/2+LFe FL, FR, FC, BL, BR, LFe
{7, SPEAKER_FRONT_LEFT|SPEAKER_FRONT_RIGHT|SPEAKER_FRONT_CENTER|SPEAKER_LOW_FREQUENCY|SPEAKER_BACK_LEFT|SPEAKER_BACK_RIGHT|SPEAKER_BACK_CENTER}, // 3/4 FL, FR, FC, BL, Bls, Brs, BR
{8, SPEAKER_FRONT_LEFT|SPEAKER_FRONT_RIGHT|SPEAKER_FRONT_CENTER|SPEAKER_LOW_FREQUENCY|SPEAKER_SIDE_LEFT|SPEAKER_SIDE_RIGHT|SPEAKER_BACK_LEFT|SPEAKER_BACK_RIGHT},// 3/4+LFe FL, FR, FC, BL, Bls, Brs, BR, LFe
};

Here the comments are wrong and I suggest the defaults (only with simple WAV header, not for WAVE_FORMAT_EXTENSIBLE):
Comments wrong Comments must be Defaults I suggest
-------------------------------------------- -------------------------------------------- ------------------------------------------
// 3/1 FL, FR, FC, Surround // 3/0+LFE FL, FR, FC, LFE // 2/2 FL, FR, SL, SR
// 3/2 FL, FR, FC, BL, BR // 3/2 FL, FR, FC, BL, BR // 3/2 FL, FR, FC, SL, SR
// 3/2+LFe FL, FR, FC, BL, BR, LFe // 3/2+LFE FL, FR, FC, SL, SR, LFE // 3/2.1 FL, FR, FC, SL, SR, LFE
// 3/4 FL, FR, FC, BL, Bls, Brs, BR // 3/3+LFE FL, FR, FC, BL, BR, BC, LFE // 3/3.1 FL, FR, FC, SL, SR, BC, LFE
// 3/4+LFe FL, FR, FC, BL, Bls, Brs, BR, LFe // 3/4+LFE FL, FR, FC, SL, SR, BL, BR, LFE // 3/4.1 FL, FR, FC, SL, SR, BL, BR, LFE

For surround channels always SL/SR, and for 4 channels FL/FR/SL/SR like is the default for aac, flac, opus and ffmpeg

[nevcairiel]

LAV Audio is a decoder filter, not a raw audio processing filter. Its not designed to handle raw PCM. Don't use it for such cases.

[clsid]

LAV currently connects using MEDIASUBTYPE_FFMPEG_AUDIO for raw PCM (pcm_s16le). It should then perhaps refuse connection for standard PCM even if Codec_PCM is enabled, so that non-standard (QT) PCM variants are still handled.

[tebasuna51]

LAV Audio is a decoder filter, not a raw audio processing filter. Its not designed to handle raw PCM. Don't use it for such cases.

What else?

WAV files aren't raw audio, WAV is a container with support for PCM INT, FLOAT and some codecs (see post #3)

LAV currently connects using MEDIASUBTYPE_FFMPEG_AUDIO for raw PCM (pcm_s16le). It should then perhaps refuse connection for standard PCM even if Codec_PCM is enabled, so that non-standard (QT) PCM variants are still handled.

Work fine but I don't know for what the dwChannelMask is not readed when all other data in fmt chunk of wav header are readed correctly.

I can't locate the source file than read the wav header in LAV Filters sources to suggest any change. Can someone help me?

[tebasuna51]

@clsid

I need to install your last ffdshow_rev4533_20140929_clsid_x64 DirectShow filter to play ok these wav files.

Also work conecting directly the LAV Spliter to the DirectSound Device, like filler56789 say.
The info than show the LAV Spliter is the same, reading correctly the dwChannelMask, I can't imagine for what the LAV Audio Decoder change it to a default based in number of channels (also with wrong defects).

[clsid]

Latest MPC-HC development build will now not use its internal LAV Audio for standard PCM.

[tebasuna51]

But external LAV Filters do the same like you can see in GraphStudioNext.

Install the ffdshow filters is not the solution, the solution is improve LAV Filters.

[FranceBB]

I'm late to the party, but I should add that when muxing a DolbyE track to mkv, it says "PCM" instead of "DolbyE".

https://i.imgur.com/mMRMHSf.png

I'm muxing the following video:


General
Complete name : W:\00_INGEST_MAM\MMA\media.dir\UPU50006_DEMUXED_1.m2v
Format : MPEG Video
Format version : Version 2
File size : 55.2 GiB
Duration : 2 h 38 min
Overall bit rate mode : Constant
Overall bit rate : 50.0 Mb/s

Video
Format : MPEG Video
Format version : Version 2
Format profile : 4:2:2@High
Format settings : BVOP
Format settings, BVOP : Yes
Format settings, Matrix : Default
Format settings, GOP : M=3, N=12
Format settings, picture structure : Frame
Duration : 2 h 38 min
Bit rate mode : Constant
Bit rate : 50.0 Mb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 FPS
Standard : Component
Color space : YUV
Chroma subsampling : 4:2:2
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.965
Time code of first frame : 06:14:59:13
GOP, Open/Closed : Closed
Stream size : 55.2 GiB (100%)
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709


with the following 4 audio tracks (DolbyE, DolbyE, PCM, PCM):

Track 1:

General
Complete name : W:\00_INGEST_MAM\MMA\media.dir\UPU50006_DEMUXED_2.wav
Format : Wave
File size : 2.54 GiB
Duration : 2 h 38 min
Overall bit rate mode : Constant
Overall bit rate : 2 304 kb/s

Audio #1
ID : 1
Format : Dolby E
Format settings : Little
Muxing mode : SMPTE ST 337
Codec ID : 1
Duration : 2 h 38 min
Bit rate mode : Constant
Bit rate : 1 291 kb/s
Channel(s) : 6 channels
Channel layout : L C Ls X R LFE Rs X
Sampling rate : 48.0 kHz
Frame rate : 25.000 FPS (1920 SPF)
Bit depth : 20 bits
Stream size : 1.42 GiB (56%)

Audio #2
ID : 2
Format : Dolby E
Format settings : Little
Muxing mode : SMPTE ST 337
Codec ID : 1
Duration : 2 h 38 min
Bit rate mode : Constant
Bit rate : 505 kb/s
Channel(s) : 2 channels
Channel layout : X X X L X X X R
Sampling rate : 48.0 kHz
Frame rate : 25.000 FPS (1920 SPF)
Bit depth : 20 bits
Stream size : 571 MiB (22%)



Track 2:


General
Complete name : W:\00_INGEST_MAM\MMA\media.dir\UPU50006_DEMUXED_3.wav
Format : Wave
File size : 2.54 GiB
Duration : 2 h 38 min
Overall bit rate mode : Constant
Overall bit rate : 2 304 kb/s

Audio #1
ID : 1
Format : Dolby E
Format settings : Little
Muxing mode : SMPTE ST 337
Codec ID : 1
Duration : 2 h 38 min
Bit rate mode : Constant
Bit rate : 1 291 kb/s
Channel(s) : 6 channels
Channel layout : L C Ls X R LFE Rs X
Sampling rate : 48.0 kHz
Frame rate : 25.000 FPS (1920 SPF)
Bit depth : 20 bits
Stream size : 1.42 GiB (56%)

Audio #2
ID : 2
Format : Dolby E
Format settings : Little
Muxing mode : SMPTE ST 337
Codec ID : 1
Duration : 2 h 38 min
Bit rate mode : Constant
Bit rate : 505 kb/s
Channel(s) : 2 channels
Channel layout : X X X L X X X R
Sampling rate : 48.0 kHz
Frame rate : 25.000 FPS (1920 SPF)
Bit depth : 20 bits
Stream size : 571 MiB (22%)




Track 3:


General
Complete name : W:\00_INGEST_MAM\MMA\media.dir\UPU50006_DEMUXED_4.wav
Format : Wave
File size : 2.54 GiB
Duration : 2 h 38 min
Overall bit rate mode : Constant
Overall bit rate : 2 304 kb/s

Audio
Format : PCM
Format settings : Little / Signed
Codec ID : 1
Duration : 2 h 38 min
Bit rate mode : Constant
Bit rate : 2 304 kb/s
Channel(s) : 2 channels
Sampling rate : 48.0 kHz
Bit depth : 24 bits
Stream size : 2.54 GiB (100%)




Track 4:


General
Complete name : W:\00_INGEST_MAM\MMA\media.dir\UPU50006_DEMUXED_5.wav
Format : Wave
File size : 2.54 GiB
Duration : 2 h 38 min
Overall bit rate mode : Constant
Overall bit rate : 2 304 kb/s

Audio
Format : PCM
Format settings : Little / Signed
Codec ID : 1
Duration : 2 h 38 min
Bit rate mode : Constant
Bit rate : 2 304 kb/s
Channel(s) : 2 channels
Sampling rate : 48.0 kHz
Bit depth : 24 bits
Stream size : 2.54 GiB (100%)





and yet:

https://i.imgur.com/OjfXHCA.png
https://i.imgur.com/erMlIzB.png

[tebasuna51]

Like Mosu say (https://forum.doom9.org/showthread.php?p=1967714#post1967714)Dolby E is not supported in mkv.

But these wav files seems correctly read like PCM like the header say (https://forum.doom9.org/showthread.php?p=1967737#post1967737).

Maybe the problem was in how these wav files are created/demuxed.

[FranceBB]

Yeah I figured it was better to stick with that discussion rather than this one, isolated, so I think we should just continue there. ;)

[tebasuna51]

Yeah I figured it was better to stick with that discussion rather than this one, isolated, so I think we should just continue there. ;)

I don't think so. In the MkvToolNix thread that discussion is closed by Mosu:

1) "Just to make it clear: I won't be spending any time on Dolby E."

And a alternative option like store wav files with wformat <> 1,3 in format A_MS/ACM also:

2) "Yes, there's the A_MS/ACM workaround, but I simply don't want to go down that road (https://forum.doom9.org/showthread.php?p=1966558#post1966558)."

But ffmpeg can mux some wav files with wformat <> 1,3.
Maybe the solution was define a wformat for Dolby E and store it like ulaw or others codecs (https://forum.doom9.org/showthread.php?p=1966534#post1966534).

How do you obtain the demuxed wav files?
Maybe with ffmpeg?
I load your .mov samples in ffmpeg and:
D:\Temp\Ptebak\Dolby E2.mov streams:

0: mpeg2video (4:2:2) (xd5c / 0x63356478), yuv422p(tv, top first), 1920x1080 [S AR 1:1 DAR 16:9], 33277 kb/s, 25 fps, 25 tbr, 12800 tbn (default)
1: pcm_s24le (in24 / 0x34326E69), 48000 Hz, stereo, s32 (24 bit), 2304 kb/s (de fault)

the audio is not recognized as Dolby E, and the forced output to wav have the wformat = 1 (stereo noise, not decoded audio)

We need extract/demux that stream with a Dolby E identifier.
ffmpeg claim support decode Dolby E, from what source?

[filler56789]

Agreeing with tebasuna51 that the discussion must continue in THIS thread...

For what analyze the well defined data as PCM INT?

The dts-wav files have a unique use: cheat the CD burner to create a CD Audio than some (not all) players can send like dts multichannel streams by spdif to AVR's
Correct (not "unaware decoders") must play the dts-wav's files like noise.
It's easy extract the correct .dts file (with less size also) from a dtswav and use it to play correctly with standard players.

The correct way to store a DTS in wav container is use the AudioFormat 0x0008.

+++++++

If we use the WAV container must follow the M$ rules, and put an AudioFormat different.

I suggest use 0xDB0E or 0x0DBE (DolBy E, like 0xF1AC is used for FLAC) not in use in 1998 RFC 2361 (https://datatracker.ietf.org/doc/html/rfc2361), also not used in last mmreg.h (https://github.com/tpn/winsdk-10/blob/master/Include/10.0.14393.0/shared/mmreg.h) I know

I've never seen a TwoCC 0x0008 sample file until today. :confused:
But if I am not mistaken, ffmpeg uses the TwoCC 0x2001 when muxing stereo or mono vanilla-DTS to .WAV through the switch -acodec copy.
However, when the DTS stream is multichannel, doesn't it require the .WAV header to use WAVE_FORMAT_EXTENSIBLE plus the appropriate GUID number
("00002001-0000-0010-8000-00AA00389B71")? :-/

For example, when ac32wav.exe adds a .WAV header to a multichannel ac3 stream, it outputs a WAVE_FORMAT_EXTENSIBLE file with the GUID "E06D802C-DB46-11CF-B4D1-00805F6CBBEA".

[tebasuna51]

The GUID's when use WAVE_FORMAT_EXTENSIBLE wav headers are defined in KSMEDIA.H (https://github.com/tpn/winsdk-10/blob/master/Include/10.0.10240.0/shared/ksmedia.h)

I found: DEFINE_GUIDSTRUCT("e06d802c-db46-11cf-b4d1-00805f6cbbea", KSDATAFORMAT_SUBTYPE_AC3_AUDIO);
but not 00002001-0000-0010-8000-00AA00389B71 for DTS

Maybe: DEFINE_GUIDSTRUCT("00000008-0000-0010-8000-00aa00389b71", KSDATAFORMAT_SUBTYPE_IEC61937_DTS);
or: DEFINE_GUIDSTRUCT("0000000b-0cea-0010-8000-00aa00389b71", KSDATAFORMAT_SUBTYPE_IEC61937_DTS_HD);
or: DEFINE_GUIDSTRUCT("e06d8033-db46-11cf-b4d1-00805f6cbbea", KSDATAFORMAT_SUBTYPE_DTS_AUDIO);

But at the moment ffmpeg don't mux WAVE_FORMAT_EXTENSIBLE (https://trac.ffmpeg.org/ticket/9703) wav's (wformat = 0xfffe) with the Codec_ID A_MS/ACM in mkv container

[nevcairiel]

WAVE_FORMAT_DTS2 is 0x2001, and you convert WAVE_FORMAT TwoCCs into GUIDs by just plugging them into the first component of the waveformat GUID, or using the DEFINE_WAVEFORMATEX_GUID macro.

DTS-in-WAV is always stereo (as its packed into a stereo 16-bit 44.1/48kHz stream, which comes out to 1411/1536kbps), independent of what the actual DTS stream contains, hence you don't need WAVE_FORMAT_EXTENSIBLE.
If it actually had WAVE_FORMAT_EXTENSIBLE with the appropriate GUID set inside, it would less of a painful format to identify and deal with, but no, you have to probe the bitstream, not just rely on header values.

Its done this way so that DTS-unaware apps will just blindly play it as PCM and external decoders will then process it as DTS. This wouldn't work if headers would actually identify it as DTS and a player would then choke on it.

[FranceBB]

I don't think so. In the MkvToolNix thread that discussion is closed by Mosu

Right, yeah, let's continue it here.



But ffmpeg can mux some wav files with wformat <> 1,3.
Maybe the solution was define a wformat for Dolby E and store it like ulaw or others codecs (https://forum.doom9.org/showthread.php?p=1966534#post1966534).


Possibly.


How do you obtain the demuxed wav files?
Maybe with ffmpeg?


Nope, I used ommcp, which is the Harmonic Omneon muxer/demuxer to demux the tracks from a feed that has been captured through an Omneon Hardware Recorder from an SDI source.

That being said, I can easily trim a few seconds of a movie showing the distributor logo with DolbyE audio and leave it in the original container, which is mxf: https://we.tl/t-fcvTPj3In4

As to the .wav files with DolbyE, according to this Dolby Document: https://developer.dolby.com/globalassets/professional/product-manuals/dolby-program-optimizer-dp600-users-manual.pdf it seems that they're saved as .wav337M so the muxing mode is "SMPTE ST 337". Such standard is "SMPTE Standard - Format for Non-PCM Audio and Data in an AES3 Serial Digital Audio Interface".

From what I found about the SMPTE document

The standard specifies an interface format for the transport of non-PCM audio and data using the AES3 serial digital audio interface. This standard includes both physical and logical specifications, based on the existing AES3 format, to allow exchange of non-PCM data between different devices. The standard accommodates multiple non-PCM audio and data formats and allows carriage of multiple data streams within a single interface. This standard provides means for carrying time code or time alignment information so that the information conveyed over this interface may be synchronized with information content delivered over other interfaces.

and indeed we can have not just DolbyE muxed as .wav but also AC3 (aka Dolby Digital) muxed as .wav and EC3 (aka Dolby Digital Plus) 7.1 muxed as .wav.


General
Complete name : File.wav
Format : Wave
File size : 2.13 GiB
Duration : 2 h 12 min
Overall bit rate mode : Constant
Overall bit rate : 2 304 kb/s

Audio #1
ID : 1
Format : Dolby E
Format settings : Little
Muxing mode : SMPTE ST 337
Codec ID : 1
Duration : 2 h 12 min
Bit rate mode : Constant
Bit rate : 1 291 kb/s
Channel(s) : 6 channels
Channel layout : L C Ls X R LFE Rs X
Sampling rate : 48.0 kHz
Frame rate : 25.000 FPS (1920 SPF)
Bit depth : 20 bits
Stream size : 1.19 GiB (56%)
Title : Program_1

Audio #2
ID : 2
Format : Dolby E
Format settings : Little
Muxing mode : SMPTE ST 337
Codec ID : 1
Duration : 2 h 12 min
Bit rate mode : Constant
Bit rate : 505 kb/s
Channel(s) : 2 channels
Channel layout : X X X L X X X R
Sampling rate : 48.0 kHz
Frame rate : 25.000 FPS (1920 SPF)
Bit depth : 20 bits
Stream size : 478 MiB (22%)
Title : Program_2


however when I open the file with an hex editor, I do see what you were showing the other day, namely the RIFF WAVE, so:

https://i.imgur.com/uPhZ7FT.png

I can send it to you, but I wouldn't know how to cut it without screwing it up.



I load your .mov samples in ffmpeg and:


the audio is not recognized as Dolby E, and the forced output to wav have the wformat = 1 (stereo noise, not decoded audio)

Yeah, I know.
Remember my .u8 workaround? (https://forum.doom9.org/showthread.php?t=176739)

Once you save the file as .u8 and you open it with ffmpeg -i, it immediately sees it as DolbyE, which is why I'm using this workaround in production, however I'd like to have wider compatibility with DolbyE files, but to achieve that and achieve proper decoding, we need FFMpeg to actually detect it all the time; something that it doesn't necessarily do. :(

I opened up a ticket in the ffmpeg bug tracker which might be worth replying to so that it goes back up and people notice it: https://trac.ffmpeg.org/ticket/9479

If we get that done and solved and implemented correctly, then we're gonna have DolbyE decoding everywhere, like in MPV https://github.com/mpv-player/mpv/issues/9353



We need extract/demux that stream with a Dolby E identifier.
ffmpeg claim support decode Dolby E, from what source?

No idea, that's why I had to use the .u8 workaround. I think it's worth asking the ffmpeg developers by replying to the ticket I made, but I'm not an audio expert here, like at all.

[tebasuna51]

Yeah, I know.
Remember my .u8 workaround? (https://forum.doom9.org/showthread.php?t=176739)

Sorry, I forget that discussion and this other about the .mxf container (https://forum.doom9.org/showthread.php?p=1955900#post1955900)

Then we are in the hands of ffmpeg developers, a full support of .mxf (about Dolby E audio) is explained in my post.

1) In order to recognize and extract a full .dbe stream, or at last using a .wav container marked with wformat 0x0DBE (or other) to previse it was played/muxed like PCM INT

2) In order to decode/convert we need a tool to select the Dolby E Program (5.1 or 2.0 in the sample) because that kind of mux is not supported in any other format. Or use the -filter_complex "asplit..." suggested in my post.

3) In order to mux in mkv container can be load like Codec_ID A_MS/ACM with a wformat 0x0DBE or 0xFFFE (WAVE_FORMAT_EXTENSIBLE) and a new defined GUID. And the LAV Filters (or equivalents) must be capable to manage this.

By the moment I don't know other way to manage Dolby E with free tools.

A workaround to work with extracted wav files by ommcp is fill with 0's the wav header in the hex editor (first 3 lines) and save it.
MediaInfo still show:
General
Complete name : C:\tmp\Test\DolbyE_mxf\Test_DolbyE.wav
Format : SMPTE ST 337
File size : 2.54 GiB
Duration : 2 h 38 min
Overall bit rate mode : Constant
Overall bit rate : 2 304 kb/s

Audio #1
ID : 1
Format : Dolby E
Format settings : Little
Duration : 2 h 38 min
Bit rate mode : Constant
Bit rate : 1 291 kb/s
Channel(s) : 6 channels
Channel layout : L C Ls X R LFE Rs X
Sampling rate : 48.0 kHz
Frame rate : 25.000 FPS (1920 SPF)
Bit depth : 20 bits
Stream size : 1.42 GiB (56%)

Audio #2
ID : 2
Format : Dolby E
Format settings : Little
Duration : 2 h 38 min
Bit rate mode : Constant
Bit rate : 505 kb/s
Channel(s) : 2 channels
Channel layout : X X X L X X X R
Sampling rate : 48.0 kHz
Frame rate : 25.000 FPS (1920 SPF)
Bit depth : 20 bits
Stream size : 571 MiB (22%)

Now ffmpeg recognize DolbyE, but:
C:\tmp\Test_DolbyE.wav streams:

0: dolby_e, 44800 Hz, 7.1, fltp

I don't see before this 44800 <> 48000
A ffmpeg detection bug? [EDIT: see next post]
The wav files created when decode have also that samplerate 44800 (for that your -ar 48000)

[tebasuna51]

MediaInfo show always a fix value of 48000:
File_DolbyE.cpp:
....
Fill(Stream_Audio, StreamPos_Last, Audio_SamplingRate, 48000);

But, if ffmpeg decoder is correct, is a wrong data.

Seems the Dolby E codec uses a samplerate dependent of fps of video to play in sync: 1 video frame <-> 1 audio frame

Also seems than the samples in a audio frame is a fix value (I don't see that in dolby-e-high-level-frame-description.pdf):

#define FRAME_SAMPLES 1792

and the allowed fps video are only: 24000/1001, 24, 25,30000/1001,30

there are the samplerates (1792 * fps):

sample_rate_tab[16] = {0, 42965, 43008, 44800, 53706, 53760}

The samples I see seems have 44800 Hz because the video fps is 25.

Of course these samplerates are invalid for other standard audio codecs and must be resampled to 44100 (downsample to CD Audio, ffmpeg default) or 48000 (upsample to standard audio movies)

[filler56789]

@tebasuna51: :goodpost:

But also: 🤯

[FranceBB]

Yes, DolbyE has an internal sampling rate that ranges according to how you set it.
I do have a setting called "Line positioning" in the Dolby DP600 software for DolbyE creation and I wonder whether it's the setting that affects the sampling rate.
I generally set it to 21 when I encode FULL HD 25i materials:

https://i.imgur.com/wLHpFyU.png

On the other hand, I had to encode several UHD files at 50p using the 25i DolbyE audio and I've simply remuxed the audio tracks.
No one complained, the delivery didn't get rejected by the studios and everything was nice and dandy, but now I wonder: did I screw up?
What happens if I mux the 25i DolbyE audio in a 50p video?
I mean, clearly it stays in sync 'cause timecodes are the same and the 50p is just the progressive version of the UHD feed from which the FULL HD 25i version originates before it got downscaled and separated in fields, so... aside from this, will something happen?
I know that with literally any other audio codec, remuxing wouldn't be a problem, but now I wonder whether with DolbyE this might be an issue due to its "special" status.

[tebasuna51]

...
On the other hand, I had to encode several UHD files at 50p using the 25i DolbyE audio and I've simply remuxed the audio tracks.
No one complained, the delivery didn't get rejected by the studios and everything was nice and dandy, but now I wonder: did I screw up?
What happens if I mux the 25i DolbyE audio in a 50p video?...

I can't help you with that, I supose you are remuxing to mxf container, if there aren't rejected seems they have the correct soft to manage it.

With modern free tools/players, all with libav filters, the Dolby E codec is not recognized and is played like noise PCM in both containers (your samples mxf and mov) despite MediaInfo can detect it.

Maybe in the future. By the moment the Dolby E audio must be recoded (using the workarounds explaining in this thread) to other format to be muxed/played with standard free soft.

[SeeMoreDigital]

Out of interest...

What is the file extension for a native Dolby E audio stream?

[tebasuna51]

What is the file extension for a native Dolby E audio stream?

I only see Dolby E muxed with video.

[FranceBB]

Yeah, I have no idea to be honest. I've only seen it muxed in .wav as 337 or indeed muxed inside videos like in .mxf or in .mov .ts .avi etc

For instance, this is what the Blackmagic Decklink recorded from a Digital BetaCAM SD File in v210 lossless muxed in .avi:


General
Complete name : \\mibctvan000.avid.mi.bc.sky.it\Ingest\MEDIA\temp\TEST_DOLBYE_AVSING07.avi
Format : AVI
Format/Info : Audio Video Interleave
Format profile : OpenDML
File size : 2.59 GiB
Duration : 1 min 38 s
Overall bit rate : 227 Mb/s

Video
ID : 0
Format : YUV
Codec ID : v210
Codec ID/Hint : AJA Video Systems Xena
Duration : 1 min 38 s
Bit rate : 221 Mb/s
Width : 720 pixels
Height : 576 pixels
Display aspect ratio : 5:4
Frame rate : 25.000 FPS
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:2
Bit depth : 10 bits
Compression mode : Lossless
Bits/(Pixel*Frame) : 21.333
Time code of first frame : 15:57:40:19 / 15:57:40:19
Time code source : Adobe tc_A / Adobe tc_O
Stream size : 2.52 GiB (98%)

Audio #1
ID : 1-1
Format : PCM
Format settings : Little / Signed
Muxing mode : Multiple
Codec ID : 00000001-0000-0010-8000-00AA00389B71
Duration : 1 min 38 s
Bit rate mode : Constant
Bit rate : 1 152 kb/s
Channel(s) : 1 channel
Sampling rate : 48.0 kHz
Bit depth : 24 bits
Stream size : 13.5 MiB (0%)

Audio #2
ID : 1-2
Format : PCM
Format settings : Little / Signed
Muxing mode : Multiple
Codec ID : 00000001-0000-0010-8000-00AA00389B71
Duration : 1 min 38 s
Bit rate mode : Constant
Bit rate : 1 152 kb/s
Channel(s) : 1 channel
Sampling rate : 48.0 kHz
Bit depth : 24 bits
Stream size : 13.5 MiB (0%)

Audio #3
ID : 1-3 / 4-1
Format : Dolby E
Format settings : Little
Muxing mode : Multiple / SMPTE ST 337
Codec ID : 00000001-0000-0010-8000-00AA00389B71
Duration : 1 min 38 s
Bit rate mode : Constant
Bit rate : 1 291 kb/s
Channel(s) : 6 channels
Channel layout : L C Ls X R LFE Rs X
Sampling rate : 48.0 kHz
Frame rate : 25.000 FPS (1920 SPF)
Bit depth : 20 bits
Stream size : 15.1 MiB (0%)
Title : ITADE-fatto_Prog0

Audio #4
ID : 1-3 / 4-2
Format : Dolby E
Format settings : Little
Muxing mode : Multiple / SMPTE ST 337
Codec ID : 00000001-0000-0010-8000-00AA00389B71
Duration : 1 min 38 s
Bit rate mode : Constant
Bit rate : 505 kb/s
Channel(s) : 2 channels
Channel layout : X X X L X X X R
Sampling rate : 48.0 kHz
Frame rate : 25.000 FPS (1920 SPF)
Bit depth : 20 bits
Stream size : 5.90 MiB (0%)
Alignment : Aligned on interleaves
Interleave, duration : 1000 ms (25.00 video frames)
Title : ITADE-fatto_Prog1