Blu-ray Dolpy Atmos 7.1 to Flac 24-bit 7.1?

[Computerman1]

Is this possible? Audacity program crashes when I try this. (ffmpeg is installed)

I backup my blu-ray to mkv file Makemkv program and many video player does not support Dolpy Atmos format.

[Ennio]

AFAIK it's not possible to keep Atmos height audiodata in flac.
You can convert Atmos to flac keeping the 7.1 TrueHD (2D) surround channels. Eac3to can do that, I have no experiewnce with ffmpeg for that matter.

[khots]

Hi!
I noticed one strange thing when decoding truehd+atmos to flac by MeGUI.
There are several decoders - LWLibavAudioSource (now default), FFAudioSource, BassAudio and NicAudio.

And only over FFAudioSource tracks is converted with higher bit-rate than the others. Truehd tracks without atmos is converted with the same bit-rate for all decoders.
Does it mean that some additional info includes in flac (unlikely, but parhaps it's atmos or some part of atmos)?

What do you think?

My results with one sample:
24183383 Bytes - 3046 kb/s - BassAudio.flac
35143469 Bytes - 4426 kb/s - FFAudioSource.flac
24183383 Bytes - 3046 kb/s - LWLibavAudioSource.flac
24183383 Bytes - 3046 kb/s - NicAudio.flac
53133320 Bytes - 6694 kb/s - ORIG.thd

[sneaker]

It probably means NicAudio, Bass and LWLibavAudioSource only decoded the AC3 "core" while FFAudioSource used the TrueHD audio. None of them can use the Atmos extension. I'm not surprised by NicAudio and Bass results as they are deprecated and really shouldn't be used anymore for this but LWLibavAudioSource should support TrueHD. Strange.

[Bernix]

Can't it be also with default Flac compression setting? Probably different in FFAudioSource. Just guess.

Bernix

[khots]

There is no AC3 inside (at least mkvmerge and eac3to can't see it)
Compression level is default everywhere, no down-mix, no normalization and so on.
Every FLAC file has 8 channels, 24 bit depth (according to Mediainfo)
I suspected that Atmos can't be encoded in flac as is, because it's object based, but sounds from Atmos can be mixed with truehd channels, I guess

I can not understand what makes this difference in bitrate

[Bernix]

https://en.wikipedia.org/wiki/FLAC#Compression_levels
I mean by this if for example ffmpeg hasn't default value compression set on 0, and others for 8 or similar.

Bernix

[sneaker]

There is no AC3 inside (at least mkvmerge and eac3to can't see it)
Compression level is default everywhere, no down-mix, no normalization and so on.

Can you cut a small sample and upload it?

[khots]

For example, "Amaze (Lossless-ATMOS)" file here https://thedigitaltheater.com/index.php/dolby-trailers/
I tried several of them with atmos and without one.
There where with atmos always bitrate higher

[sneaker]

Thx. As you say it doesn't have an AC3 core at all. Which begs the question how you could open it with NicAudio at all. It isn't possible. Maybe MeGUI tried to extract via eac3to but eac3to actually encoded to .ac3 (lossy!) when it couldn't find any core to extract? MeGUI log should tell you what happened.

What I can see as difference between l-smash and ffms: ffms outputs 32 bit while l-smash output 24 bits. IIRC TrueHD is 24 bit max so ffms does it wrong. In the PCM data you can see all bits >24 are 0 anyways. When eac3to encodes the ffms output to FLAC it sees the 0s and reduce the depth to 24 bit. Maybe it does some unnecessary dithering which increases compression difficulty?

[pandy]

ffmpeg flac is 2992kbps.

@ffmpeg.exe -v 32 -stats -y -hide_banner -i "%1" -vn -c:a flac -compression_level 12 "%~n1.flac"

ffmpeg flac seem to have this defaults:

Encoder flac [FLAC (Free Lossless Audio Codec)]:
    General capabilities: delay small 
    Threading capabilities: none
    Supported sample formats: s16 s32
FLAC encoder AVOptions:
  -lpc_coeff_precision <int>        E...A... LPC coefficient precision (from 0 to 15) (default 15)
  -lpc_type          <int>        E...A... LPC algorithm (from -1 to 3) (default -1)
     none                         E...A...
     fixed                        E...A...
     levinson                     E...A...
     cholesky                     E...A...
  -lpc_passes        <int>        E...A... Number of passes to use for Cholesky factorization during LPC analysis (from 1 to INT_MAX) (default 2)
  -min_partition_order <int>        E...A... (from -1 to 8) (default -1)
  -max_partition_order <int>        E...A... (from -1 to 8) (default -1)
  -prediction_order_method <int>        E...A... Search method for selecting prediction order (from -1 to 5) (default -1)
     estimation                   E...A...
     2level                       E...A...
     4level                       E...A...
     8level                       E...A...
     search                       E...A...
     log                          E...A...
  -ch_mode           <int>        E...A... Stereo decorrelation mode (from -1 to 3) (default auto)
     auto                         E...A...
     indep                        E...A...
     left_side                    E...A...
     right_side                   E...A...
     mid_side                     E...A...
  -exact_rice_parameters <boolean>    E...A... Calculate rice parameters exactly (default false)
  -multi_dim_quant   <boolean>    E...A... Multi-dimensional quantization (default false)
  -min_prediction_order <int>        E...A... (from -1 to 32) (default -1)
  -max_prediction_order <int>        E...A... (from -1 to 32) (default -1)

[khots]

When I tried to convert over eac3to I saw very interesting info in report
First, each channel has different depth.
Second, some channels have variable depth!

I didn't even know what it could be like that!

Probably FFAudioSource really makes some depth scaling, that's why bit-rate is higher

eac3to v3.34
command line: D:\Progs\MeGUI-dev-64\tools\eac3to\eac3to.exe  TRUEHD.thd TRUEHD.flac
------------------------------------------------------------------------------
TrueHD (Atmos), 7.1 channels, 48kHz
Decoding with libav/ffmpeg...
Encoding FLAC with libFlac...
Creating file "TRUEHD.flac"...
Original audio track, L+LFE+BL: constant bit depth of 18 bits.
Original audio track, R+SL: constant bit depth of 19 bits.
Original audio track, C+SR: max 23 bits, average 18 bits.
Original audio track, BR: max 22 bits, average 18 bits.
eac3to processing took 27 seconds.
Done.

So my conclusion - don't use FFAudioSource when you converting to flac, and there is no atmos

[pandy]

When I tried to convert over eac3to I saw very interesting info in report
First, each channel has different depth.
Second, some channels have variable depth!

I didn't even know what it could be like that!

Probably FFAudioSource really makes some depth scaling, that's why bit-rate is higher

eac3to v3.34
command line: D:\Progs\MeGUI-dev-64\tools\eac3to\eac3to.exe  TRUEHD.thd TRUEHD.flac
------------------------------------------------------------------------------
TrueHD (Atmos), 7.1 channels, 48kHz
Decoding with libav/ffmpeg...
Encoding FLAC with libFlac...
Creating file "TRUEHD.flac"...
Original audio track, L+LFE+BL: constant bit depth of 18 bits.
Original audio track, R+SL: constant bit depth of 19 bits.
Original audio track, C+SR: max 23 bits, average 18 bits.
Original audio track, BR: max 22 bits, average 18 bits.
eac3to processing took 27 seconds.
Done.

So my conclusion - don't use FFAudioSource when you converting to flac, and there is no atmos

Your conclusion may be incorrect and also reported bit depth may be related to mixing/decoding issues - variable bit depth means how many bits are used from overall number of bits - if level in channel is lower than maximum (i.e. 0dBFS) then such channel has lower bitdepth and this is normal for digital representation of analogue signals - for example 1bit is equal approx to 6dB so if signal is -12dBFS (dB Full Scale) then efficiently use 2 bit less than overall number of bits (in case of 16 bit PCM this mean only 14 bits are used). Not knowing whole signal processing chain you may incorrectly interpret statistical data.

You can visualize how many bits are used with help:

@set name=%1
@ffplay -f lavfi -i "amovie=%name%,asplit=2[out0][audio];[audio]abitscope=rate=30:size=qhd[out1]"

Seem ffmpeg is consistent with eac3to on reported bitdepth