+ Reply to Thread
Results 1 to 13 of 13
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
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.
Can't it be also with default Flac compression setting? Probably different in FFAudioSource. Just guess.
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
I mean by this if for example ffmpeg hasn't default value compression set on 0, and others for 8 or similar.
Last edited by Bernix; 6th Jan 2018 at 08:21. Reason: typo
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
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?
ffmpeg flac is 2992kbps.
@ffmpeg.exe -v 32 -stats -y -hide_banner -i "%1" -vn -c:a flac -compression_level 12 "%~n1.flac"
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)
Last edited by pandy; 7th Jan 2018 at 10:34.
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.
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]"
Last edited by pandy; 10th Jan 2018 at 07:04.