[FFmpeg-devel] MLP Multichannel for DVD-Audio

[fabrice nicol]

I've recently been integrating the ffmpeg encoder into the DVD-Audio 
creating software dvda-author (https://dvd-audio.sourceforge.io), 
command-line options --encode and --mlp-files

1. The good news is that multichannel ffmpeg-encoded MLP audio overall 
plays back fine on a DVD-Audio player (using ffmpeg MLP encoder in its 
current git master branch).

2. The bad news is  that for 16-bit audio, for 6 channels 96 kHz only, 
the audio playback is audible, not hissing, but quite out of sync, with 
echo effects.

3. Hints at issues

Using 6/16/96 MLP files generated by a proprietary tool from the same 
wav files, the corresponding DVD-Audio discs play fine.

I made diffs of 6/16/96 MLP files and what comes out is that proprietary 
tools use 2 streams for multichannel, whilst the ffmpeg MLP encoder does 
seem to use just one. This strategy seems to fail for 6/16/96.

In the two bytes after sync major tags (0xF8726FBB): a 6/16/96 
proprietary-encoded mlp file will be encoded 0x00 11, which means the 
bit depth and sample rate are likewise encoded for two streams, whilst 
ffmpeg-encoded mlp files at corresponding offsets will be encoded 0F1F, 
which looks like the second stream bit depth and sample rate are not set.

4. Related issues

The compression rate of proprietary tools is massively higher when using 
channels with high audio redundancy. I built limit cases, in which the 
original PCM multichannel is just one channel identically replicated to 
the other channels. Below is a table of corresponding compression 
outcomes. The extra compression offered by the proprietary tool is 
massive for multichannel, noticeable for stereo 48 kHz and negligible in 
other cases.

channels/bit depth/sample rate kHz 	ffmpeg (B) [a]
	proprietary (B) [b]
	Extra compression = [(b-a)/a]
1_16_176 	3037274 	3041922 	0 %
1_16_192 	3237328 	3241950 	0 %
1_16_88 	1619992 	1622424 	0 %
1_16_96 	1757208 	1759616 	0 %
2_16_176 	3073990 	3078694 	0 %
2_16_192 	3276318 	3280994 	0 %
2_16_48 	1019046 	753728 	-26 %
2_24_48 	1019046 	753728 	-26 %
2_24_88 	1659590 	1588338 	-4 %
2_24_96 	1799546 	1684128 	-6 %
3_16_44_Lf_Rf_S 	1852486 	611528 	-67 %
3_16_48_Lf_Rf_C 	2618092 	765854 	-71 %
3_16_88_Lf_Rf_C 	4579130 	848546 	-81 %
3_16_96_Lf_Rf_C 	4965218 	883742 	-82 %
3_24_44_Lf_Rf_S 	2415790 	1168382 	-52 %
3_24_48_Lf_Rf_S 	2618092 	1614514 	-38 %
3_24_88_Lf_Rf_S 	4578426 	1596642 	-65 %
3_24_96_Lf_Rf_S 	4962790 	1692648 	-66 %
4_16_44_Lf_Rf_Ls_Rs 	2431314 	618832 	-75 %
4_16_48_Lf_Rf_Ls_Rs 	3436386 	774834 	-77 %
4_16_88_Lf_Rf_Ls_Rs 	6054248 	857118 	-86 %
4_16_96_Lf_Rf_C_LFE 	6564428 	893794 	-86 %
4_24_44_Lf_Rf_Ls_Rs 	3171060 	1168038 	-63 %
4_24_48_Lf_Rf_Ls_Rs 	3436386 	1671526 	-51 %
4_24_88_Lf_Rf_Ls_Rs 	6053300 	1604566 	-73 %
4_24_96_Lf_Rf_Ls_Rs 	6560980 	1701338 	-74 %
5_16_44_Lf_Rf_LFE_Ls_Rs 	3043118 	626716 	-79 %
5_16_48_Lf_Rf_C_Ls_Rs 	4259698 	785564 	-82 %
5_16_88_Lf_Rf_LFE_Ls_Rs 	7572646 	866594 	-89 %
5_16_96_Lf_Rf_LFE_Ls_Rs 	8210736 	903800 	-89 %
5_24_44_Lf_Rf_Ls_Rs_LFE 	3969708 	1180472 	-70 %
5_24_48_Lf_Rf_Ls_Rs_LFE 	4301712 	1712056 	-60 %
5_24_88_Lf_Rf_Ls_Rs_LFE 	7571414 	1612840 	-79 %
5_24_96_Lf_Rf_LFE_Ls_Rs 	8206676 	1710184 	-79 %
6_16_44_Lf_Rf_C_LFE_Ls_Rs 	3592854 	633664 	-82 %
6_16_48_Lf_Rf_C_LFE_Ls_Rs 	5078744 	796240 	-84 %
6_16_88_Lf_Rf_C_LFE_Ls_Rs 	9011680 	876884 	-90 %
6_16_96_Lf_Rf_C_LFE_Ls_Rs 	9770740 	914614 	-91 %
6_24_44_Lf_Rf_C_LFE_Ls_Rs 	4686942 	1196392 	-74 %
6_24_48_Lf_Rf_C_LFE_Ls_Rs 	5078744 	795452 	-84 %
6_24_88_Lf_Rf_C_LFE_Ls_Rs 	9010250 	1621502 	-82 %
6_24_96_Lf_Rf_C_LFE_Ls_Rs 	9765734 	1720278 	-82 %

My question is: is this caused by the fact that the ffmpeg MLP encoder 
only uses one substream?

Fabrice Nicol