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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
