eac3to - audio conversion tool

[tebasuna51]

I went back and double checked... Libav and ArcSoft give me a real LFE channel with the core, not a full range channel at a low volume.
You are right, my first spectral analysis was wrong.

I wonder if the file is incorrectly flagged as discrete but is actually matrix.
Changing the Extended Coding Flag, in standard DTS header, to 0 eac3to show the file as:

DTS Master Audio, 6.1 channels, 24 bits, 48kHz
(core: DTS-ES, 5.1 channels, 24 bits, 1509kbps, 48kHz)

DTS-ES, 5.1 is like eac3to show a 6.1 matrixed.

Decoding the DTS-MA the output is the same than before, but decoding the core the output is only 5.1 without the empty BC channel.

In order to obtain a -downDpl mix, like you want in your first post, I can only suggest extract the core and use BeHappy.

Or edit the core with a hex editor replacing all hex values:
7FFE8001FC3C7DB277001D
with
7FFE8001FC3C7DB277000D
and use eac3to.

[jj666]

Hi,
I have a problem when I try to extract video streams from "MONSTERS INC 3D".
I have this message one time for each video stream : [v02] The video bitstream framerate field doesn't seem to match the timestamps. <WARNING>
And several warnings like that : [v02] Video has a gap of 14 frames at playtime 0:00:00. <WARNING>
On playlist info, it is indicated "48p /1.001" but streams are 24p/1001.
I have also tried with the new TsMuxer and no problems.
Anyone can help me ?
Thanks !

If you wait until the end of the spam, it ends up with one extra frame in the MVC stream, which would mean it's not remuxable anyway (at least not in Scenarist, without manually editing the .VES file).

Video track 2 contains 132552 frames.
Video track 3 contains 132553 frames.

I noticed there are a lot of branched files on this disk, so perhaps this is the reason for the problem.

1) 00000.mpls, 1:32:09
[800+879+880+1002+1006+881+1008+1010+1014+1016+1020+1022+1026+1028+1032+883+1
034+1040+1042+1046+1048+1052+885+886+887+888+1054+1058+889+1060+1062+1066+891+89
2+908].m2ts

If Madshi is interested in checking this one out, have no issue to donate the original disk.

Cheers,

-jj-

[laserfan]

These posts from June 2011 (a different thread) inspires me to ask: does anyone know which dlls came from which Arcsoft TMT versions?

I have a couple dozen Setup files for TMTs including v2 thru v6, but I only have one version actually installed to a PC. Would be nice to know what dlls came with which vs. trying to install each and hunt them down...!

:eek:

EDIT: Here's one data point:

I added in my past post (http://forum.doom9.org/showthread.php?p=1508578#post1508578) information about 2.1 bug.

Also I ran eac3to with all 1.1.0.x versions of arcsoft decoder on lossy DTS files. As I understand eac3to patches streams to mark it 24 bit and to make all arcsoft versions output 24 bit. In this case outputs of all versions except 1.1.0.0 are identical.

So the final conclusion is following: the best version of dtsdecoderdll.dll is 1.1.0.1. It decodes all lossy streams to 24 bit, it doesn't have mono and 6.0 bugs, its decoding algorithm for lossy and lossless content wasn't changed in latter versions (except mono and 6.0 of course). The only problem of 1.1.0.1 (and all arcsoft versions) - silent LFE channel in 2.1 streams.

PS Version 1.1.0.1 came with the original release of TMT3, 3.0.1.120.

The elaboration posted earlier in this thread:

I tested 5 different versions of dtsdecoderdll.dll along with LAV Audio, here are results.

Versions tested: 1.1.0.0, .1, .5, .7, .8.

Samples tested:
1) Lossy DTS 2.0, 2.1, 5.1, 6.0, 6.1 configs, 16/48, 24/48 and 24/96 bitdepth/sample rate;
2) DTS-MA 1.0, 2.0, 2.1, 5.1, 6.1, 7.1 configs including 7.1 "strange setup" config (eac3to term), 16/48, 24/48, 24/96 variants.
My results differ from results that some people posted in eac3to thread, I guess there may be some eac3to specific problems.

lossy DTS
1) 1.1.0.0 and 1.1.0.1 always decode lossy DTS as 24 bit, and their decoding results differ from each other.
2) 1.1.0.5 and up decode in proper bitdepth.
3) Versions 1.1.0.5 and up decode lossy DTS identically.
4) 1.1.0.1 and 1.1.0.5 decode 24 bit lossy DTS identically.
5) Decoding of 16 bit lossy DTS was changed from 1.1.0.0 to 1.1.0.1 and from 1.1.0.1 to 1.1.0.5.
6) 1.1.0.7 and 1.1.0.8 decode 6.0 without back center channel.

The conclusion for lossy: I assume the best version for lossy DTS is 1.1.0.5. It decodes all configurations I've tested, in proper bitdepth, and decoding algorithm didn't change since this version (except 6.0 bug in .7 and .8).

DTS-MA
All versions output identical streams except mono case. Mono decoding was broken in 1.1.0.5 and partially fixed in 1.1.0.8 (outputs as stereo). Note that MA 7.1 16/48 "strange setup" is decoded as 24/48 by all versions.

The conclusion for lossless: the best versions are 1.1.0.0 and 1.1.0.1.

Of course, to be sure that decoding is done properly some "reference proper" decoder is needed. I don't have it.

EDIT: Forgot to mention about 2.1 bug. None of the versions can decode LFE channel in 2.1 files.

[Nico8583]

If you wait until the end of the spam, it ends up with one extra frame in the MVC stream, which would mean it's not remuxable anyway (at least not in Scenarist, without manually editing the .VES file).

Video track 2 contains 132552 frames.
Video track 3 contains 132553 frames.

I noticed there are a lot of branched files on this disk, so perhaps this is the reason for the problem.

1) 00000.mpls, 1:32:09
[800+879+880+1002+1006+881+1008+1010+1014+1016+1020+1022+1026+1028+1032+883+1
034+1040+1042+1046+1048+1052+885+886+887+888+1054+1058+889+1060+1062+1066+891+89
2+908].m2ts

If Madshi is interested in checking this one out, have no issue to donate the original disk.

Cheers,

-jj-
For me, streams contain the same number of frame...

[mikeyakame]

I've done a few tests with the reference DTS-HD decoder and it appears at least the version of dtsdecoder.dll from TMT 5.3 did somewhat decode a 5.1 ( L R C LFE Ls Rs ) HD-MA bit exact.

I say somewhat because Arcsoft's decoder padded the stream on output and the resulting length was around ~30-40ms longer than the original PCM audio which the Master Audio stream was encoded from.

To get the Arcsoft output to line up with the reference decoder output, I had to remove a bunch of empty samples before and after the bit exact region (With a trusty hex editor no less). Just for reference the decoded channels from the DTS-HD reference decoder (it only decodes to mono wav files) were bit for bit exact with the mono wavs I originally fed the encoder.

[Sparktank]

TMT 5.3

What version of the dtsdecoder.dll is that?

[filler56789]

I've done a few tests with the reference DTS-HD decoder and it appears at least the version of dtsdecoder.dll from TMT 5.3 did somewhat decode a 5.1 ( L R C LFE Ls Rs ) HD-MA bit exact.

I say somewhat because Arcsoft's decoder padded the stream on output and the resulting length was around ~30-40ms longer than the original PCM audio which the Master Audio stream was encoded from.

To get the Arcsoft output to line up with the reference decoder output, I had to remove a bunch of empty samples before and after the bit exact region (With a trusty hex editor no less). Just for reference the decoded channels from the DTS-HD reference decoder (it only decodes to mono wav files) were bit for bit exact with the mono wavs I originally fed the encoder.

:goodpost: Thanks for testing and confirming what was already discussed (and explained) in the thread below,

http://forum.doom9.org/showthread.php?t=168133

[mikeyakame]

Looked into it just now, and the reason the Arcsoft Decoder is outputting "junk" is because this junk is supposed to be discarded when decoding back to pcm. Going off what I've learnt, I believe eac3to needs to be responsible for this step.

From the start of the DTS-HD file.

CORESSMD HEADER + 0x20

0x30 + 3 bytes = Core Sample Rate Hz
0x33 + 2 bytes = Core Bitrate Kbps
0x35 + 4 bytes = Channel Mask
0x39 + 2 bytes = Frame Payload in Bytes

EXTSS_MD HEADER + 0x3C

0x4C + 3 bytes = Extended Avg Bitrate Kbps
0x4F + 3 bytes = Extended Peak Bitrate Kbps
0x52 + 2 bytes = Peak Bitrate Smoothing Buffer Size Kb

AUPR-HDR + 0x54.

0x67 + 3 bytes = Source Sample Rate
0x6A + 4 bytes = DTS Frame Count
0x6E + 2 bytes = DTS Frame Size in Samples
0x70 + 1 byte = Appears to mean Codec Delay Samples [ delay_samples / frame_size frames ] are included in the DTS Frame Count when its value is 0.
0x71 + 4 bytes = Source Sample Count (Encoded from PCM)
0x75 + 2 bytes = Bitmask? [ 0x02 = Ext is Lossless, 0x01 is probably used for DTS Express where the Ext Stream is lossy and CBR ]
0x77 + 2 bytes = Codec Delay in Samples


That's pretty much all the data you need to calculate how many samples of the decoded PCM you need to discard from the beginning and the end.

I'll use my working file as an example.


Source Sample Count = 68154486
Arcsoft Decoded Sample Count = 68155904


Difference between the source PCM and the Arcsoft decoded PCM is 1418 samples. In this case it amounted to 2836 bytes for a single channel.


1418 samples * 2 byte depth = 2836 bytes


I binary compared the source and the decoded output and determined that there was 2048 bytes extra at the beginning, and 788 bytes extra at the end.

So now to our DTS-HD header values.


DTS Encoded Frames = 133117
DTS Frame Size = 512 samples
Codec Delay = 1024 samples

Source Sample Count = 68154486


Codec delay should be time allowed to index the audio and build the frame navigation table and what not, so it comes first.


codec_delay / dts_frame_size = 2 frames

source_samples / dts_frame_size = 133114 full frames + 118/512 frame

2 ( 512 codec_delay_samples ) + 133114 ( 512 source_samples ) + 1 ( 118/512 source_samples ) = 113117


The header says the encoded DTS-HD file has 113117 frames, so we got our maths right.

Back to our decoded differences.
We have +2048 bytes at the beginning.


Codec Delay = 1024 samples * 2 bytes depth = 2048 bytes.


We discard the first 2048 bytes of each channel because they are padding and not from the source pcm.

Now we have +788 bytes left at the end.

788 bytes / 2 bytes depth = 394 samples


These samples were not from our source PCM, so we must discard them too.

So, why 394 exactly?


1 full DTS Frame = 512 samples
Last DTS Frame = 118 samples

512 - 118 = 394


And that is where the mysterious 394 samples at the end appeared from.

Arcsoft's DTS decoder appears to decode all padding into the PCM output instead of discarding it like the Reference DTS-HD decoder does.

eac3to just needs to calculate if there are padded frames, and discard these when writing out the pcm data or after the fact.

Hope this helps, was kinda fun to figure out.

[hdtv00]

You guys way deep into this and I don't know what happened or if I'd just been lucky.

I rip my concert blu rays using eac3to,hdbrstreamextractor and playback using waspi. My older rips all seem to be the right 24 bit 96khz but last two I've tried have been down sampled for 48khz. New Bryan Adams and Bee Gee's. Did something break in my setup. Has DTS Master audio never ripped correctly. I see it trying the different decoders, it settles on libav, say arcsoft isn't doing it yet i have it installed.

[mikeyakame]

Well checked one of my Blu-rays and demuxed the DTS-HD stream, it appears the header and the navigation table are both stripped when muxed into m2ts.

In that case I'll do some more tests just to confirm whether the codec_delay is fixed at 2 frames and whether the frame_size is fixed at 512 samples (which they most likely are, but want to be 100% sure.) If that is the case, the first 1024 samples could probably be safely discarded. The only time I can see the partial frame and codec_delay becoming a problem is when seemless branching is used. Not too sure how this is handled.

[tebasuna51]

Well checked one of my Blu-rays and demuxed the DTS-HD stream, it appears the header and the navigation table are both stripped when muxed into m2ts.
Yes, that is know. The main header than encoder (like DTS MA Master Suite) put at the begining is a help to BD Authoring soft, and the muxer can transfer the data to container header but the stream itself can't contain a main header, each DTS frame have a header.

I think the muxer must also strip the delay frames because I never see DTS tracks with delay in BD's.

I can confirm than eac3to ignore this main header and the frame delay is not applied, then the output have a initial delay.

The problem don't exist with extracted DTS from any container and is not related with seemless branching.

The sample with I work have also 2 delay frames and framesize 512 samples.

I don't know if encoders always put 2 frames delay. Seems DTS MA Master Suite yes.

The frame size can have different values but 512 is the standard, I never see other.
BTW, the frame size is stored in each DTS frame header and is know without the main header.

[Q-the-STORM]

just got this after demuxing a blu-ray

[v02] Waiting for DirectShow decoder thread to finish. Please wait...

only posts I found containing this got the demux process "Aborted at file position XXX", not here though, no error messages, everything looks the same, with the exception of that line...

this is first time I saw it, seems to be straight forward to what it means, so I'm not really worried, just wanted to know if anyone else got this before, without any errors in the files....

[tebasuna51]

@Q-the-STORM
I never see that.
Please put the full log, to know, at least, the video track than need a "DirectShow decoder".

[Q-the-STORM]

I just deleted the log a minute ago...

but there was nothing special there... it was an episode of a TV show, all other episodes didn't have it, only one of them had the line, everything else was the same, so there's really no info to get from the log...

[maxmercy]

I have a question:

I have run into this issue on multiple occasions, where the LFE channel on a TrueHD track is severely clipped, but its AC3 counterpart is not.

Please see the attached pic, the top track is the AC3 LFE channel, and the bottom track is the TrueHD version.

I decoded to .wav for analysis with the libav decoder.

Are there any known issues with the libav decoder that would cause this?

JSS

[kevmitch]

...the DTS HD MA sound from the Obilivion blu ray. In short, the center channel becomes distorted in loud bits.

Sorry I seem to be late in checking back on this. Hopefully the initial responders are still watching this thread.

There really two possibilities here:

1) The soundtrack is badly mastered with hard limiting/compression or just plain clipping.

2) The arcsoft decoder is producing incorrect output from the .dtshd input.

The main thing I want to know is wether or not someone can reproduce the distortion with a licensed decoder (either hardware or software). This should be compared with my FLAC samples to make sure that you know what you're looking for. If you can confirm that the FLACS have the distortion, but the licenced decode of either the .dtshd file (or preferrably the original blu-ray) does not, then we have a decoding rather than mastering problem. Proving a true mastering problem may be difficult if multiple licenced decoders have a similar bug to arcsoft (maybe firmware upgrades are necessary?).


Have you tried the Arcsoft decoder 1.1.0.9 ?

Does anyone finally know what improvements or regressions version 1.1.0.9 brings?

It produces identical output sample for sample in this case.


BTW, as you are saying the tiny distortion you are getting in your sample is in the original track as well. But, starting at the same time up to 20 seconds later (not in your sample) there often is A LOT of sound clipping (and in other parts of the movie too).


I'm not hearing any problems here.


So, if PowerDVD plays the (Arcsoft decoded) FLAC fine but 2 different ffmpeg players on 2 different systems don't, ffmpeg is the issue.
So, as far as I can see, this is a bug in ffmpeg.

Once you've got the FLAC, it should either work on all players or none at all since it is lossess. Every flac decoder should produce identical output, which is not a hard problem since the spec is completely open. It's possible a given decoder has a bug, but I have not found any evidence for this. I also have the bare minimum of cruft between my decoder and speakers. No effects or anything. I hear the distortion in windows (vlc,winamp,MPC-HD). But I also get the same results in Linux (audacity, audacious, mplayer, vlc) with direct ALSA output.


I tried listening to the FLAC center channel samples posted above, and i couldn't really hear any obvious distortions, but maybe i just dont know what to listen for (or my player is fixed)

Between 2.5s and 3.0s in the above sample (8:15 in the film) is where it distorts. It's easy to miss because there's a lot of sound going on there. It presents as a high frequency scratching/crackling/rapid popping. I can hear it on numerous different audio/decoder setups, but it is most apparent with my etymotic in-ear earphones which have a very flat frequency response. Try using an equaliser to boost the high frequencies and it's unmistakable.


Even opening in Audacity it didn't show any clipping (marked in red). It does show that it's cut off at .8 ("The vertical scale displays amplitude when showing the waveform" from Audacity Help)

I also looked at the waveforms in audacity and visually saw the same "hard limiting" effect, which indeed seems to suggest bad mastering. However, I can't yet rule out the possibility that it's bad decoding - maybe arcsoft is mistakenly clipping at 0.8? The fact that the MA and core differ in amplitude (see next quote) gives me a bad feeling.


4) But there are a problem that I never see. The lossless output from DTS-MA decoded with ArcSoft is 3dB loud than the decoded core (ArcSoft or libav).
Not only on clip parts but over the full sample.


Interesting, I can confirm this!


1.) Oblivion ripped w/o errors, so whatever problems the disc might exhibit are not due to disc defects,


In both the bad mastering and bad decode scenarios, there would be no errors ripping from the disc. With bad mastering, a bad signal is correctly encoded to the disc. This would produce no errors except playing back the original bad signal. With bad decoding, the error hasn't happened until after ripping.


2.) whatever problems one might have with the sound are due to the player/playback software, cuz MPC-HC plays it perfectly.


I can still hear the distortion when I try the .dtshd file with MPC-HC. Or rather I had to mux the .dtshd to an .mka because MPC doesn't handle .dtshd directly.

I have a question:

I have run into this issue on multiple occasions, where the LFE channel on a TrueHD track is severely clipped, but its AC3 counterpart is not.

Please see the attached pic, the top track is the AC3 LFE channel, and the bottom track is the TrueHD version.

I decoded to .wav for analysis with the libav decoder.

Are there any known issues with the libav decoder that would cause this?

JSS
The following may be of interest

4) But there are a problem that I never see. The lossless output from DTS-MA decoded with ArcSoft is 3dB loud than the decoded core (ArcSoft or libav).
Not only on clip parts but over the full sample.

[maxmercy]

The following may be of interest
Quote:
Originally Posted by tebasuna51 View Post
4) But there are a problem that I never see. The lossless output from DTS-MA decoded with ArcSoft is 3dB loud than the decoded core (ArcSoft or libav).
Not only on clip parts but over the full sample.

I see the problem with both DTS-HDMA and DolbyTrueHD, and mainly in the LFE channel. Curiously, Here are the three tracks, Top is AC3, middle is THD with 120Hz steep lowpass and then normalized, and last is THD untouched. Curious...

JSS

[mp3dom]

Is it possible to change the filename convention for the surround tracks as Ls/Rs instead of SL/SR (at least for 5.1)
A lot of professional tools uses this naming convention (L/R/C/Lf (or Lfe)/Ls/Rs). For example, encoders like dts-HD MAS searches for that naming convention so when you feed the first channel (usually the left) to the encoder, it takes all the other channels automatically (this also avoid possible errors while passing manually the files).
Tnx.

[kevmitch]

I see the problem with both DTS-HDMA and DolbyTrueHD, and mainly in the LFE channel. Curiously, Here are the three tracks, Top is AC3, middle is THD with 120Hz steep lowpass and then normalized, and last is THD untouched. Curious...

JSS


Using my DTSHD-MA 7.1 channels, 24 bits, 48kHz DTSHD-MA sample (https://dl.dropboxusercontent.com/u/60598588/oblivion_distort.zip) from above (http://forum.doom9.orgshowthread.php?p=1640665#post1640665), I find that versions 1.1.0.0, 1.1.0.7, 1.1.0.8,1.1.0.9 all produce the same "lossless" decode as I mentioned previously

However, when I pull out the -core (core: DTS, 5.1 channels, 24 bits, 1509kbps, 48kHz), using all four versions listed above, they are all quieter than the lossless decode by approximately the same ammount. The most obvious sign is that the signal is clipped at 0.6 rather than 0.8. But it is also quiter in non-clipped parts as pointed out by tebasuna51 (http://forum.doom9.org/showthread.php?p=1641423#post1641423).

On top of this difference in amplitude between the lossy and lossless, the 1.1.0.0 decoder produces different core (lossy) output from 1.1.0.7, 1.1.0.8 and 1.1.0.9. The latter three produce identical lossy results.

It appears that all versions of the arcsoft decoder for DTS as well as the libav decoder for truehd (as you've shown) exhibit amplitude discrepancies between lossy and lossless output. That's two distinct decoders for two distinct codecs which is kind of spooky. Maybe it's "supposed" to be like that for some reason.

[kevmitch]

I should add that I've also tried -keepDialnorm, on both the lossless and lossy decodes, which produces identical files.

[maxmercy]

Using my DTSHD-MA 7.1 channels, 24 bits, 48kHz DTSHD-MA sample (https://dl.dropboxusercontent.com/u/60598588/oblivion_distort.zip) from above (http://forum.doom9.orgshowthread.php?p=1640665#post1640665), I find that versions 1.1.0.0, 1.1.0.7, 1.1.0.8,1.1.0.9 all produce the same "lossless" decode as I mentioned previously

However, when I pull out the -core (core: DTS, 5.1 channels, 24 bits, 1509kbps, 48kHz), using all four versions listed above, they are all quieter than the lossless decode by approximately the same ammount. The most obvious sign is that the signal is clipped at 0.6 rather than 0.8. But it is also quiter in non-clipped parts as pointed out by tebasuna51 (http://forum.doom9.org/showthread.php?p=1641423#post1641423).

On top of this difference in amplitude between the lossy and lossless, the 1.1.0.0 decoder produces different core (lossy) output from 1.1.0.7, 1.1.0.8 and 1.1.0.9. The latter three produce identical lossy results.

It appears that all versions of the arcsoft decoder for DTS as well as the libav decoder for truehd (as you've shown) exhibit amplitude discrepancies between lossy and lossless output. That's two distinct decoders for two distinct codecs which is kind of spooky. Maybe it's "supposed" to be like that for some reason.

Or maybe a way to phase out DD/DTS Lossy, as the Lossless tracks will be perceived to be 'better' due to higher levels....who knows. There are many DTSHD and DTHD decodes I have analyzed that do not clip the LFE channel like above, but some tracks do...maybe a mistake in post-production.

JSS

[kevmitch]

Or maybe a way to phase out DD/DTS Lossy, as the Lossless tracks will be perceived to be 'better' due to higher levels....who knows. There are many DTSHD and DTHD decodes I have analyzed that do not clip the LFE channel like above, but some tracks do...maybe a mistake in post-production.

JSS
LOL. The sad thing is you're probably right.

[DoctorM]

A question. Applying slowdown to a PAL Dolby audio track as such:
eac3to "AudioFile_80.ac3" "NTSC.wav" -down16 -slowdown -25.000
AC3, 2.0 channels, 1:24:57, 192kbps, 48kHz, dialnorm: -27dB
Removing AC3 dialog normalization...
Decoding with libav/ffmpeg...
Changing FPS from 25.000 to 23.976...
Reducing depth from 64 to 16 bits...
Writing WAV...
Creating file "NTSC.wav"...
eac3to processing took 15 minutes, 4 seconds.
Done.

I then tried to load the resulting .wav into a better quality Dolby encoder, except it wouldn't load.
I loaded the .wav into Sony Sound Forge and resaving (making no changes). That file loads fine.

Original File:
Audio
ID : 0
Format : PCM
Format settings, Endianness : Little
Format settings, Sign : Signed
Codec ID : 00001000-0000-0100-8000-00AA00389B71
Duration : 1h 28mn
Bit rate mode : Constant
Bit rate : 1 536 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Stream size : 973 MiB (100%)

Resaved file:
Audio
ID : 0
Format : PCM
Format settings, Endianness : Little
Codec ID : 1
Duration : 1h 28mn
Bit rate mode : Constant
Bit rate : 1 536 Kbps
Channel(s) : 2 channels
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Stream size : 973 MiB (100%)

So where is the problem coming from? Is there something I should be changing on the eac3to command line to make it more compatible?

[Groucho2004]

So where is the problem coming from?
Possibly the extensible WAVE header that eac3to writes. Try adding the switch "-simple".

[DoctorM]

Bingo! Thanks.

Btw, has there been talk about doing something to allow eac3to to remove the dialog normalization during transcoding and then if the output is ac3 embed a normalization again?
Basically allow the source and encode to have the same normalization when finished?

[tebasuna51]

Basically allow the source and encode to have the same normalization when finished?

Apply the same Dialog Normalization than source when recode is your choice.

If you only play Dolby Digital files can be a good idea, but if you play different files (DTS, MP3, AAC, FLAC, ...) maybe is better put Dialog Normalization to -31 to avoid low volume.

[DoctorM]

Is there a switch to add a normalization to AC3 encodings? I haven't seen that. I don't mean -keepDialnorm (which alters the original audio), I mean something like -DialNorm 27.

[tebasuna51]

You need use the external Aften.exe encoder:

eac3to input stdout.wav | Aften -b 640 -readtoeof 1 -dnorm 27 - output.ac3

[DoctorM]

At that point it's just as easy to decode to the AC3 to WAV and then use a separate encoder.
Didn't know aften supported dnorm though.

[Groucho2004]

Is there a switch to add a normalization to AC3 encodings? I haven't seen that. I don't mean -keepDialnorm (which alters the original audio), I mean something like -DialNorm 27.
This (http://forum.doom9.org/showthread.php?t=56020) is a good (and necessary) read in case you're planning on adding dialog normalization and/or DRC.

[laserfan]

Don't use -keepDialnorm never with ac3 or dts (I don't know with TrueHD), let eac3to work.

I must admit that the more I read about this, and the more I surf on it, the less I understand about it.

:o

I have always left eac3to alone, which of course means to remove dialnorm, but occasionally I notice that when I make backups of BD discs and keep the "director commentary" track, these always blow you out of your seat it seems, because they sound very much louder than the base program. Is dialnorm related to this in any way? Should I be keeping dialnorm for these tracks?

It seems Dialog Normalization must have a purpose or it wouldn't be in the standard--when is it needed??? Who here can explain this so mere mortals can understand it?

:confused:

[DoctorM]

The simple answer: An audio track is at whatever volume. The dialog normalization number tells your audio decoder that it is loud or soft by so much and that it must adjust the volume to keep it at a standard level.

In theory it should make all audio tracks sound roughly the same volume. Without it most audio tracks will be louder than they should be.

While I wouldn't want to use -keepDialnorm since that physically adjusts the track's volume when decoding, reapplying a dialog normalization number to an ac3 track after re-encoding make sense.

I always use a true Dolby encoder after Eac3to does its thing for this reason.
You could also try a program like VOBDNorm to add on a dial. norm. after the fact.

[laserfan]

I wouldn't want to use -keepDialnorm since that physically adjusts the track's volume when decoding, reapplying a dialog normalization number to an ac3 track after re-encoding make sense.

If Dialog Normalization is authored into AC3 tracks on BD discs, presumably by a smart sound guy in the studio's Authoring facility, to tell a player's/amp's DD decoder to adjust [the Center channel?] up-or-down, what is the reason for stripping it out when doing these demux/remux processes? Why would you want to strip it out and then reapply; what do you know that the original sound guy doesn't?

Sorry if these are dumb questions--I'm REALLY not getting this. :(

[DoctorM]

Dial. norm. adjust the global volume, not just the center. It is intended to do so in a manner that makes the dialog level a specific volume though.

In theory using -keepDialNorm would be more accurate if you're going back to AC3 (whereas encodings tend to boost the volume to the maximum it can reach without clipping, so the D.N. would be undesirable.)
It's more(?) lossy to reduce the volume of an audio track while decoding and then re-encoding with no dialog normilzation level (technically -31db).

Subtle detail may be lost, especially since AC3 tracks tend to already be mixed at a lower level (peaking 80% or less of maximum).

Anyone who has listened to an AC3 track and then a CD or mp3 will have noticed this. Honestly, there shouldn't be a difference, but mixing CD's at 100% peak is a throw back to analog recordings.

[laserfan]

Thank you DoctorM, I think I am getting closer. At least, it seems clear(er) to me now that dialnorm is an attempt to include in the recording some information that is useful if you are trying to maintain a reference sound level for the dialogue in a program, in order to have some consistency when listening to multiple programs and maintaining the same setting on the amplifier. Which is not the case (for me at least) in racking-up a BD and watching a movie or concert film (I adjust volume up or down as needed to the program).

The only circumstance that I can see dialnorm as beneficial then might be if one were to make a compilation disc of favorite movie scenes or song/concert performances, so as to (try to) maintain that consistency--though I'd still imagine there'd be wide differences at least with concert film clips.

Anyway thanks for replying to me, I appreciate it. :)

[DarkSpace]

I think the main purpose of DialNorm is to achieve a consistent volume for multiple audio tracks on the same disc. Say, you've got a disc with audio in the movie's original language and your local language, then DialNorm is supposed to make switching between local and original audio possible without having to readjust volume levels on your playback equipment.

[tebasuna51]

Like idea use DialNorm is good, the problem is when Dolby Digital tracks must compete with other sources like DTS (can have a DialNorm but is not used most the times), commercials in TV, CD audio (Loudness war (http://en.wikipedia.org/wiki/Loudness_war))...

There are many users than ask for more volume in DD tracks.
A standard value for DialNorm in DD tracks is -27, that mean than a DD decoder must attenuate all sound by 4 dB.
Many movies have DTS and DD tracks with different volume because that.

Not problem with DD tracks in different languages when the DialNorm is changed from -27 to -31 in all, maybe a commentary track can have a different DialNorm, check this before.

BTW Aften (included in eac3to) don't make DD compliant tracks, is only a A/52 (AC-3) audio encoder.
Who want a DD track please read the post recommended by Groucho2004 and use a commercial DD compliant encoder.

@DoctorM
To make a DD track after the slowdown you can use a DD encoder with the same DialNorm (and DRC) than source without problems.

[laserfan]

I think the main purpose of DialNorm is to achieve a consistent volume for multiple audio tracks on the same disc. Say, you've got a disc with audio in the movie's original language and your local language, then DialNorm is supposed to make switching between local and original audio possible without having to readjust volume levels on your playback equipment.

This makes a lot of sense, but it also argues for keeping dialnorm when using eac3to to demux-then-remux a disc with e.g. Director's Commentary track(s) as I do.

Now that I think of it, BD-RB uses tsMuxeR to demux and I imagine that tsMuxeR doesn't touch the dialnorm metadata.

Guess I have to re-think my processing methods. Recently I noticed the Dir Commentary audiotrack on a disc I had to re-do (for subtitle issues) was very much louder than the main audio so I used eac3to (and Aften I think) to lower it by some 6dB. Maybe if I'd kept dialnorm for these this would not have been necessary? :o

[Q-the-STORM]

I'm wondering... since FLAC was updated to 1.3.0 and 6.1/7.1 channel masks from input WAV files were fixed, shouldn't there be a an update of eac3to with a new libFLAC?

[mastrboy]

You can update it yourself by updating the libFLAC.dll file with a newer one.

[sneaker_ger]

Quoting madshi:
FLAC 1.3.0 has just officially sanctioned what eac3to has been doing all along. So there's nothing for me to change.

[sl1pkn07]

eac3to mkv muxer in linux (with wine) still don't work (yes, I have installed haali and -test says correct)

any help for why happen this?

greetings

[tebasuna51]

53 posts moved to new thread How to run eac3to (http://forum.doom9.org/showthread.php?t=169530)

[mindbomb]

i just noticed you can do audio delays in eac3to.
if im making an mkv, would it make more sense to delay the audio directly with eac3to or is it better to do it with mkvmerge?

[the_weirdo]

Maybe you should delay the audio directly with eac3to if possible. Standalone players and some splitters/decoders may not hornor the delay information in Matroska. But it's just my opinion and I'm not an expert on this.

[LigH]

If you do a (possibly lossy) conversion with encoding, like dts to AC3, it is certainly recommendable to handle the delay already during that conversion, to get a perfectly synced result.

But if you just extract core audio, without actually encoding (e.g. EAC3 to AC3, DTS-HD to Core dts), I would suggest to just keep the delay.

[tebasuna51]

...
But if you just extract core audio, without actually encoding (e.g. EAC3 to AC3, DTS-HD to Core dts), I would suggest to just keep the delay.

I think you want say "TrueHD to AC3", because EAC3 to AC3 is a recode.

BTW, I always apply the delay even in extractions. Is your choice.

[nevcairiel]

Technically, from Blu-ray EAC3 tracks, you can also extract a "core" AC3. It uses a concept of dependent frames, which means the 5.1 core is coded in basic AC3, and there are 4 channels coded as E-AC3 which replace the downmixed back channels in the 5.1 and add 2 more channels for full 7.1

[LigH]

You probably know this part better than me, I have so little material to be converted...

Also it may depend on the technique used to fix the delay, and the sign. Omitting preceding audio frames is simple; prepending "known silence blocks" only works as long as they are really well known.

[tebasuna51]

@nevcairiel
You are right, I forget this option added in v3.25:

v3.25
...
* added support for demuxing Blu-Ray primary E-AC3 tracks (AC3 core)

But BD's tracks TrueHD are more common than EAC3.