eac3to - audio conversion tool

[madshi]

Process:
- I demuxed a two channel .WAV and encoded to DTS-HD MA.
- Demuxing (or rather splitting the outputted .DTSHD) to individual .WAVs with DTS StreamPlayer results in an identical to
original source file when compared to original in Adobe Audition.
- Demuxing (or rather splitting the outputted .DTSHD) to individual .WAVs with EAC3TO results in an file with +21ms delay when compared to original in Adobe Audition.
Then I can only guess that there's additional information in the DTSHD header which tells the decoder to cut off 21ms from the beginning of the track. 21ms should be exactly 2 DTS frames. Or maybe the DTS StreamPlayer always cuts off 2 DTS frames? I've no idea. What I can say is that eac3to is not doing anything fancy, it just strips of the DTSHD header and feeds the DTS frames to the ArcSoft decoder. As far as I can see, eac3to is doing exactly the right thing.

Of course I could add extra processing to eac3to to always ignore the first 2 DTS frames when there's a DTSHD header, but then who guarantees us that it's always 2 frames? Maybe sometimes it's only 1 frame or 3 frames?

[jj666]

In my experience encoding LPCM (2.0 and 5.1) to DTS-HD MA, it's always 21ms (as mentioned in the past, I demuxed first with TSMUXER to remove header, then processed with EAC3TO). That's probably around 100 encodings and all waveform checked with Adobe Audition (and 21ms removed after with EAC3TO).

That's my experience, but like you said there may be certain circumstances where this is different. I would humbly request that the 21ms be automatically removed to save me a step in my process, but that's up to you :-) What I can say is that I will report back if I ever see sync issues different to 21ms :-)

Cheers,

-jj-

[madshi]

Ok, so should I only ignore the first 2 frames when there's a DTSHD header? When there's no such header, I should not cut off 2 frames?

Can you please try "eac3to source.dts dest.wavs -21ms" to check whether the WAV files are then perfectly identical to the DTS StreamPlayer output?

[jj666]

Hello Madshi,

Thanks for your quick reply. Yes, its less than a millisecond out. I took the liberty of making some samples for you:-

DTS-HD (60mb): http://www.mediafire.com/?49x9zs9up9uhvh9
DTS StreamPlayer demuxed left channel (30mb): http://www.mediafire.com/?gfmwkaa4pqhmea4
EAC3TO -21ms demuxed left channel (30mb): http://www.mediafire.com/?88484ugdeiehbzz
EAC3TO demuxed left channel (30mb): http://www.mediafire.com/?36y5labf5uqw1vf

Audition (same file order):

http://thumbnails24.imagebam.com/9336/53bd9f93358609.jpg (http://www.imagebam.com/image/53bd9f93358609)

Let me know in case you need any more info. As mentioned, this sync issue does not apply to a straightforward demux from a Blu-ray, it's only happening where the DTS-HD contains the header information.

Cheers,

-jj-

[Thunderbolt8]

is there possibly a very small bug with the red colour of "the format of the source file could not be detected"?

doesnt seem to appear normally, but I did "eac3to movie.htm movie.srt > moviefinal.srt" (basically I accidently used eac3to command instead of srtmaker.exe, that small file to combine OCR'ed subs (timestamps + spoken text)) and then after that sentence above, the path "X:\" also had that red background colour and every line after as well.

srtmaker.exe in order to reproduce: http://www.mediafire.com/?zzqihdc5p11bkjn

[rapscallion]

Here (http://rghost.net/1659797) they are.
SNR:
out.10N.nero.L.wav 27.386 dB
out.10N.libav.L.wav 27.411 dB
out.10S.nero.L.wav 5.5173 dB
out.10S.libav.L.wav 27.398 dB
tartak (http://forum.doom9.org/member.php?u=169863) wrote on another forum, that with nero decoder DRC is only partially ignored: volume increasing still applies, while attenuation is ignored.

Goal is to decode Dolby/TrueHd 5.1 to wavs.

From several previous posts, it was stated that Nero decoder doesn't handle drc removal properly. An example was given, as a comparison to libav, that the snr was substantially different. Is this really true and, if so, why was their no problem all the time that this was considered a "fine" decoder.
(still is in madshi's first post of the thread)

No other user has mentioned problems with either the audio quality or the snr of Nero since the beginning of this thread 3 years ago.
A google search doesn't reveal the CompAudio program used to measure the outputs. Anyone know where to find it or does it go by a different name ?

When using Nero (in eac3to_more gui) the dialog box states that drc is being disabled, however when using libav no such msg. Is libav removing drc or not ?

Separate curiousity question :

Blue Thunder contains both a ac3 and THD track. Why is it that the THD track is 16bit (24 bit padded) and yet the ac3 track is 24 bit (eac3to reduces from 64 to 24)? Logic would indicate that it should be just the opposite.

When decoding these tracks to wavs, the HD tracks result in ~600mb files and the ac3 tracks to ~900mb files. Again, seems like it should be just the opposite or is the size the resullt of the different bit depths.

This is starting to make my head hurt !

[Thunderbolt8]

there was some talk that lossy tracks dont have a real bitdepth or something like that, so just ignore the 24-bit.

[rik1138]

well, I dont have a HD receiver yet, so I wouldnt know if I needed it ;) but if I had to redo something then I'd like to have done that by the time I have that kind of receiver, thats why I ask.

It only affects DTS-HD files created by the DTS Encoder (before they've been used on a Blu-ray disc). If you are only demuxing from existing discs, it has no affect on you.

Madshi- Thanks so much for adding this! Saves me the hassle of having to remove the headers when I need to convert files! :cool:

[Abradoks]

No other user has mentioned problems with either the audio quality or the snr of Nero since the beginning of this thread 3 years ago.
madshi has already tried (http://forum.doom9.org/showthread.php?p=1404212#post1404212) to fix it.
A google search doesn't reveal the CompAudio program used to measure the outputs. Anyone know where to find it or does it go by a different name ?
Actually first link (http://www-mmsp.ece.mcgill.ca/documents/Software/Packages/AFsp/CompAudio.html) in google. It's part of AFsp (http://www-mmsp.ece.mcgill.ca/Documents/Downloads/AFsp/) package.
BTW, you can use any other tool to compute SNR.
Is libav removing drc or not ?
Yes, it doesn't apply DRC by default.

[rapscallion]

madshi has already tried (http://forum.doom9.org/showthread.php?p=1404212#post1404212) to fix it.
Yes, I saw his post but didn't think it was an eac3to issue, but a Nero issue.
Isn't it the Nero decoder that's removing/disabling drc?

Or am I misunderstanding how the decoder processes the stream to wavs ?


Actually first link (http://www-mmsp.ece.mcgill.ca/documents/Software/Packages/AFsp/CompAudio.html) in google. It's part of AFsp (http://www-mmsp.ece.mcgill.ca/Documents/Downloads/AFsp/) package.
BTW, you can use any other tool to compute SNR.
Thanks, however I actually saw that link but didn't see anywhere to download the file, just an explanation of what it does. Am I missing something ?

Yes, it doesn't apply DRC by default.
By "apply" do you mean it removes it when decoding an ac3 track? Because that's what I'm looking for the decoder to do.

[nurbs]

By "apply" do you mean it removes it when decoding an ac3 track? Because that's what I'm looking for the decoder to do.
It removes it on demuxing and doesn't apply it on decoding which is essentially the same as removing it.

[rapscallion]

Gotcha, thanks !

[Abradoks]

Or am I misunderstanding how the decoder processes the stream to wavs ?
DRC is metainformation. By default Nero decoder always applies DRC when such information is presented. eac3to uses some hacks to avoid it, but as you see it doesn't work always. On the contrary, with libav you have full control over this and by default it doesn't apply DRC. So you don't need to "remove" anything.

Thanks, however I actually saw that link but didn't see anywhere to download the file, just an explanation of what it does. Am I missing something ?
Here is direct link: AFsp-v8r2.tar.gz (http://www-mmsp.ece.mcgill.ca/Documents/Downloads/AFsp/AFsp-v8r2.tar.gz). win32 binaries are in MSVC/bin folder.

[rapscallion]

DRC is metainformation. By default Nero decoder always applies DRC when such information is presented. eac3to uses some hacks to avoid it, but as you see it doesn't work always. On the contrary, with libav you have full control over this and by default it doesn't apply DRC. So you don't need to "remove" anything.
Ok, I really did misunderstand that process. And now I see why it was so long before the problem was discovered.
Reminds me of years ago when I worked for the Norwegian audio co Tandberg. The running joke was that the name translated to "intermittent".

Here is direct link: AFsp-v8r2.tar.gz (http://www-mmsp.ece.mcgill.ca/Documents/Downloads/AFsp/AFsp-v8r2.tar.gz). win32 binaries are in MSVC/bin folder.

Thank you again and for the link..... had to go back to my command prompt days to do this one :)

[Atak_Snajpera]

Newer versions (e.g. 1.1.0.7) of the dtsdecoder.dll seem to have this problem. Older versions (e.g. 1.1.0.0) work just fine.
Does older version contain any serious bugs which were fixed in newer? In other words. Is it safe to downgrade decoder to older version?

[tebasuna51]

Does older version contain any serious bugs which were fixed in newer? In other words. Is it safe to downgrade decoder to older version?
v1.1.0.0 works fine for me, without know bugs, with XP SP3.

[MikeEby]

Hmmmmm... This is a difficult one. Sometimes there might be a small intro with different channels before the real movie which I could easily ignore without doing any damage. But then there might be movies where actually different parts have different audio tracks (e.g. seamless branching theatrical cut vs. director's cut). How can eac3to know? E.g. if the first m2ts file is 10 minutes long, shall I still cut it away? For an intelligent human it's not so difficult to find out whether an m2ts file can be dropped or not, but for a computer program it's much more difficult. I fear that if I simply drop the first m2ts file if it has different audio track properties, then I might damage some real movies.

Thoughts?

(BTW, the frame rate is not different, eac3to is more or less "guessing" the m2ts framerate, it's sometimes wrong. The video track framerate is reliable and it's identical.)

I've run into a couple of disks with playlists such as this too. The latest one is called “Dead Man Running”.

Perhaps if eac3to could look at the first 2 files in the playlist and then it notices they do not have matching tracks it could then use only the file with the higher track count and longest time. If the track counts don’t match eac3to will fail anyway, so there would be nothing to loose. The chapter times would also have to be offset by missing file length. Maybe if the first file is less than 30 seconds long just drop it, or perhaps a switch?

Mike

[Atak_Snajpera]

Hmmmmm... This is a difficult one. Sometimes there might be a small intro with different channels before the real movie which I could easily ignore without doing any damage. But then there might be movies where actually different parts have different audio tracks (e.g. seamless branching theatrical cut vs. director's cut). How can eac3to know? E.g. if the first m2ts file is 10 minutes long, shall I still cut it away? For an intelligent human it's not so difficult to find out whether an m2ts file can be dropped or not, but for a computer program it's much more difficult. I fear that if I simply drop the first m2ts file if it has different audio track properties, then I might damage some real movies.

Thoughts?

(BTW, the frame rate is not different, eac3to is more or less "guessing" the m2ts framerate, it's sometimes wrong. The video track framerate is reliable and it's identical.)


I agree with MikeEby. eac3to should compare two first files in playlist. File with higher number of channels should be kept. File with lower number of channels should be automatically discarded.

I've run into a couple of disks with playlists such as this too.
MikeEby can you provide samples or at least logs like mine
eac3to v3.22
------------------------------------------------------------------------------
1) 00014.mpls, 00034.m2ts+00014.m2ts, 2:35:21
- Chapters, 35 chapters
- VC-1, 1080p24 /1.001 (16:9)
- AC3, German, stereo, 48kHz

00034.m2ts
M2TS, 1 video track, 1 audio track, 0:00:37, 29.766p
1: Chapters, 35 chapters
2: VC-1, 1080p24 /1.001 (16:9)
3: AC3, German, 2.0 channels, 192kbps, 48kHz, dialnorm: -27dB

00014.m2ts
M2TS, 1 video track, 1 audio track, 0:00:29, 24p /1.001
1: VC-1, 1080p24 /1.001 (16:9)
2: AC3, German, 5.1 channels, 640kbps, 48kHz, dialnorm: -27dB

[mrr19121970]

Or change the way the info is presented, currently:

M2TS, 1 video track, 1 audio track, 0:20:43, 50i
1: Chapters, 4 chapters
2: MPEG2, 576i50 (16:9)
3: AC3, German, 2.0 channels, 192kbps, 48kHz

if streams differ in underlying .m2ts files

00001.M2TS, 1 video track, 1 audio track, 0:00:43, 50i
1: Chapters, 4 chapters
2: MPEG2, 576i50 (16:9)
3: AC3, German, 2.0 channels, 192kbps, 48kHz

00002.M2TS, 1 video track, 1 audio track, 0:20:00, 24p
4: VC-1,1080p24 (16:9)
5: DTS, German, 5.1 channels

[nautilus7]

madshi,

"-mono" switch to output only center channel (in mono wavs) doesn't seem to work correctly when a second pass is needed.

eac3to v3.24
command line: eac3to audio.thd audio.bd.wavs -mono
------------------------------------------------------------------------------
TrueHD, 5.1 channels, 48kHz
Decoding with libav/ffmpeg...
Writing WAVs...
Creating file "audio.bd.C.wav"...
[libav] Lossless check failed - expected 0, calculated c <WARNING>
The original audio track has a constant bit depth of 16 bits.
Superfluous zero bytes detected, will be stripped in 2nd pass.
Starting 2nd pass...
Decoding with libav/ffmpeg...
Reducing depth from 24 to 16 bits...
Writing WAVs...
Creating file "audio.bd.L.wav"...
Creating file "audio.bd.C.wav"...
Creating file "audio.bd.SR.wav"...
Creating file "audio.bd.LFE.wav"...
Creating file "audio.bd.R.wav"...
Creating file "audio.bd.SL.wav"...
The processed audio track has a constant bit depth of 16 bits.
eac3to processing took 21 minutes, 21 seconds.
Done.

[Snowknight26]

Hate to nag, but any hopes of getting -check working with SRT subs in an upcoming build? ASS subs work fine, but SRT..

[chompy]

I don't know if this is a bug, or if that's what's meant to be, but demuxed H264 videos cannot be opened with Adobe Premiere, while the same videos demuxed with tsMuxeR can be opened and edited perfectly.

Greetings

EDIT: The files I'm demuxing are m2ts ripped from bluray

[b66pak]

I agree with MikeEby. eac3to should compare two first files in playlist. File with higher number of channels should be kept. File with lower number of channels should be automatically discarded.

what about movies like "Fireflies In The Garden"?

Logo 1, Channels: 2.0, 10.400s
Logo 2, Channels: 5.1, 4.992s
Logo 3, Channels: 2.0, 15.680s
Movie, Channels: 5.1

it should stay as it is...
_

[Momber]

The FLAC is correct. ... If you still get incorrect channel assignments then it's the fault of some other filter
I'm not in the least surprised to hear that.

eac3to and madFlac definitely handle 3.0 correctly now.
Great! Thank you very much.

[tormento]

I am trying to convert "American Gangster" extended edition from BD to MKV.

Firstly I have to correctly demux every track but a problem exist.

The standard lenght is composed by the following M2TS:

2:36:50

235+222
236+223
237+224
238+225
239+226
240+227
241+228
242+229
243+230
244+231
245+232
246+233
247+234
248

The extended lenght from the following:

2:55:46

235+249
236+250
237+251
238+252
239+253
240+254
241+255
242+256
243+257
244+258
245+259
246+260
247+261
248

The standard lenght has every language and subs, the extended only the english in the alternative M2TS.

I need the italian+english(when italian missing) extended version. How is possible to tell eac3to to select a particular stream from a M2TS and changing it while joining?

[MikeEby]

MikeEby can you provide samples or at least logs like mine

Here you go.
The Girl With The Dragon Tatoo (US Version)

1) 00001.mpls, 2:33:02
[1+0+17+18].m2ts
- Chapters, 17 chapters
- h264/AVC, 1080p24 /1.001 (16:9)

00001.m2ts
M2TS, 1 video track, 0:00:10, 24p /1.001
1: h264/AVC, 1080p24 /1.001 (16:9)

00000.m2ts
M2TS, 1 video track, 2 audio tracks, 1 subtitle track, 2:32:44, 24p /1.001
1: h264/AVC, 1080p24 /1.001 (16:9)
2: AC3, Swedish, 5.1 channels, 448kbps, 48kHz, dialnorm: -27dB
3: AC3, English, 5.0 channels, 448kbps, 48kHz, dialnorm: -27dB
4: Subtitle (PGS), English

00017.m2ts
M2TS, 1 video track, 0:00:04, 24p /1.001
1: h264/AVC, 1080p24 /1.001 (16:9)

00018.m2ts
M2TS, 1 video track, 0:00:04, 24p /1.001
1: h264/AVC, 1080p24 /1.001 (16:9)



Mary and Max (US Version) This one has matching track counts just the track properties don't match.


1) 00000.mpls, 00023.m2ts+00000.m2ts, 1:32:26
- Chapters, 17 chapters
- h264/AVC, 1080p24 /1.001 (16:9)
- RAW/PCM, English, stereo, 48kHz
- RAW/PCM, English, stereo, 48kHz
- RAW/PCM, English, stereo, 48kHz
- RAW/PCM, English, stereo, 48kHz

2) 00007.mpls, 00007.m2ts, 0:22:04
- MPEG2, 480i60 /1.001 (16:9)
- RAW/PCM, English, stereo, 48kHz
- RAW/PCM, English, stereo, 48kHz
- RAW/PCM, English, stereo, 48kHz
- RAW/PCM, English, stereo, 48kHz

3) 00002.mpls, 00005.m2ts, 0:15:48
- Chapters, 6 chapters
- MPEG2, 480i60 /1.001 (4:3)
- RAW/PCM, English, stereo, 48kHz
- RAW/PCM, English, stereo, 48kHz
- RAW/PCM, English, stereo, 48kHz
- RAW/PCM, English, stereo, 48kHz

00023.m2ts
M2TS, 1 video track, 4 audio tracks, 2 subtitle tracks, 0:00:10, 24p /1.001
1: h264/AVC, 1080p24 /1.001 (16:9)
2: RAW/PCM, English, 2.0 channels, 16 bits, 48kHz
3: RAW/PCM, English, 2.0 channels, 16 bits, 48kHz
4: RAW/PCM, English, 2.0 channels, 16 bits, 48kHz
5: RAW/PCM, English, 2.0 channels, 16 bits, 48kHz
6: Subtitle (PGS), Spanish
7: Subtitle (PGS), English

00000.m2ts
M2TS, 1 video track, 4 audio tracks, 2 subtitle tracks, 1:32:16, 24p /1.001
1: h264/AVC, 1080p24 /1.001 (16:9)
2: RAW/PCM, English, 2.0 channels, 24 bits, 48kHz
3: DTS Master Audio, English, 5.1 channels, 24 bits, 48kHz core: DTS, 5.1 channels, 24 bits, 1509kbps, 48kHz)
4: RAW/PCM, English, 2.0 channels, 16 bits, 48kHz
5: RAW/PCM, English, 2.0 channels, 16 bits, 48kHz
6: Subtitle (PGS), Spanish
7: Subtitle (PGS), English




Dead Man Running This one has matching track counts too...Different audio types in the two files. My original thought won't work.


1) 00001.mpls, 00009.m2ts+00003.m2ts, 1:31:48
- Chapters, 12 chapters
- h264/AVC, 1080p24 /1.001 (16:9)
- DTS, English, stereo, 48kHz
- DTS, English, stereo, 48kHz

2) 00005.mpls, 00011.m2ts, 0:23:55
- h264/AVC, 1080i60 /1.001 (16:9)
- DTS, English, stereo, 48kHz

3) 00004.mpls, 00010.m2ts, 0:23:12
- h264/AVC, 1080i60 /1.001 (16:9)
- DTS, English, stereo, 48kHz

00009.m2ts
M2TS, 1 video track, 2 audio tracks, 0:00:15, 24p /1.001
1: h264/AVC, 1080p24 /1.001 (16:9)
2: DTS, English, 2.0 channels, 16 bits, 510kbps, 48kHz
3: DTS, English, 2.0 channels, 16 bits, 510kbps, 48kHz

00003.m2ts
M2TS, 1 video track, 2 audio tracks, 1:31:32, 24p /1.001
1: h264/AVC, 1080p24 /1.001 (16:9)
2: DTS Master Audio, English, 5.1 channels, 16 bits, 48kHz core: DTS, 5.1 channels, 16 bits, 1509kbps, 48kHz)
3: DTS, English, 2.0 channels, 16 bits, 768kbps, 48kHz



Thanks!
Mike

[setarip_old]

@tormento

Hi! I am trying to convert "American Gangster" extended edition from BD to MKV.That's a simple task for MakeMKV (including stream selection)...

[krosswindz]

I am using the eac3to v3.24 to extract wave files from a DTS MA source. I noticed that the wave files have a bitrate of 1152kbps though the core is 1509 kbps. I am using the arcsoft DTS decoder v1.1.0.0. I extracted the wave files using the following command line


c:\path\to\eac3to.exe e:\path\to\blu-ray\source 1) 3: output.wavs


I am wondering is there something that I am doing wrong. If I extract the core as wave files the bitrate is again at 1152 kbps.

[TinTime]

No, nothing's wrong. The bitrate of a PCM WAV file is always going to be (bitdepth * sample rate * channels / 1000) kbps. More specifically bitdepth will be rounded up to the nearest byte.

So in your example it's 24 * 48000 * 1 / 1000 = 1152kbps

It doesn't matter if the source is lossy or lossless. If they both decode to the same bitdepth then the resultant wavs will be the same size.

[tormento]

That's a simple task for MakeMKV (including stream selection)... [/Color]
Sorry, I have tried but Make MKV sees only the eng audio for the extended version.. My will is to use the eng audio where the ita audio is missing... I could try to encode every M2TS separately and join them but doing this would not correct the audio gaps and so.

[krosswindz]

No, nothing's wrong. The bitrate of a PCM WAV file is always going to be (bitdepth * sample rate * channels / 1000) kbps. More specifically bitdepth will be rounded up to the nearest byte.

So in your example it's 24 * 48000 * 1 / 1000 = 1152kbps

It doesn't matter if the source is lossy or lossless. If they both decode to the same bitdepth then the resultant wavs will be the same size.

Thanks for clearing the confusion.

[krosswindz]

I am not sure if this feature exists already but it would be nice if one is able to use some form of a queue for processing in eac3to. For example if one wants to create both 768Kbps DTS and 1536 Kbps DTS eac3to could only extract the wave files once. Currently, I do the extraction myself and then use surcode encoder manually.

[TinTime]

I am not sure if this feature exists already but it would be nice if one is able to use some form of a queue for processing in eac3to. For example if one wants to create both 768Kbps DTS and 1536 Kbps DTS eac3to could only extract the wave files once. Currently, I do the extraction myself and then use surcode encoder manually.

If your source is DTS MA with a full rate core as mentioned in your earlier post then then just extract the core and add the half rate file separately.
c:\path\to\eac3to.exe e:\path\to\blu-ray\source 1) 3: output1.dts -core 3: output2.dts -768
More generally you might be able do the following:
c:\path\to\eac3to.exe e:\path\to\blu-ray\source 1) 3: output1.dts -1536 3: output2.dts -768
I've never tried it but give it a go :)

If the problem is that it takes a long time to decode your source audio then another option is to decode to wav first and then encode from that wav - it won't take so long to split to wavs:
c:\path\to\eac3to.exe e:\path\to\blu-ray\source 1) 3: inter.wav
c:\path\to\eac3to.exe inter.wav output1.dts -1536
c:\path\to\eac3to.exe inter.wav output2.dts -768

[jasonwc]

Ok, so should I only ignore the first 2 frames when there's a DTSHD header? When there's no such header, I should not cut off 2 frames?

Can you please try "eac3to source.dts dest.wavs -21ms" to check whether the WAV files are then perfectly identical to the DTS StreamPlayer output?

I did some testing and found that I got a 24 ms delay. I took a TrueHD track from Dexter (16/48 Khz) and converted to FLAC. I then converted the TrueHD to mono WAVS and used the Master Audio Suite to create a DTS-HD MA. Here's what I found:

Decoded FLAC - 54:09.288 (155965840 samples)
Decoded TrueHD- 54:09.288 (155965840 samples)
Decoded DTS-HD MA- 54:09.312 (155966976 samples)

The DTS-HD MA has an extra 24 ms of samples (1,136 samples). I used the foobar2000 bit-comparison tool and found that the TrueHD and FLAC tracks were bit-identical.

I used eac3to remove 24 ms, but I was still a few samples short. Is there a way to remove an exact number of frames? In any case, I'm not sure why I'm getting a 24 ms rather than a 21 ms delay.

Like the others, when I decode to WAV with the DTS HD Streamplayer, there are no extra samples, and the output matches the source in foobar's bit-comparison tool.

[Thunderbolt8]

so far ive only had delays of 21ms as well.

[sub24ox7]

BUG report:
I have a disc that has a 24 bit 96 khz 5.1 LPCM track when extracting the LPCM (eac3to movie.m2ts 4: audio.wavs) as pcm or wav(s) the runtime is twice as long as it should be with the new eac3to 3.24 so I reverted to the only other copy I had on my computer which was 3.17 I think and the LPCM track extracted fine. Also the M2ts had a 1080i60 video track in it.

[ramicio]

I wonder about the order of processing, and this is why I haven't ventured to use eac3to for certain tasks. Anything with a lossless 5.1 track I find I demux to wavs with eac3to. Then with goldwave I mix these into a stereo 24/192 wav, resample to 24/96, and then use eac3to to flac it. If I could just do a 1 step process to do this that would be nice.

Lossless 5.1 -> 6 x 24/192 -> downmix -> 24/96 -> flac

I also do downmixing like:

Left = Center + LFE + FL + RL
Right = Center + LFE + FR + RR

So I don't know how anything else does it. After that of course it is clipped, but Goldwave thankfully stores everything in floating point that is being worked on, so I just find the highest peak and reduce the volume by that MINUS 0.01 dB.

[Alcohor]

madshi, first of all thank you for your wonderful tool :D

i have a "little" request for you... can you add an option that can split .m2ts files by chapters (like dvddecrypter)? i've got a lot of bluray of tv series that contain all episodes merged in one .m2ts and i'd like to make them separated

[nurbs]

@ramicio:

You can't get that downmix with eac3to.

-down2 uses a DPLII downmix with
L' = 0.5 x L + 0.3535 x C + 0.433 x SL + 0.250 x SR
R' = 0.5 x R + 0.3535 x C - 0.250 x SL - 0.433 x SR
with -mixlfe you also add that to it.

eac3to will use 64 bit precision for processing. Output precision will be same as input if you encode lossless, highest supported by the encoder if you encode lossy. Clipping will be detected and automatically dealt with. You can change the sampling rate, apply gain or normalize the audio if you like. It's in the manual.

By the way, the downmix you use is not standard AFAIK. A standard normalized stereo downmix uses
L' = 0.3694 x L + 0.2612 x C + 0.3694 x SL
R' = 0.3694 x R + 0.2612 x C + 0.3694 x SR

[ramicio]

Yes, I know what eac3to can do. It's the order of it I was asking about. Is that downmix mapping really optimal for lossless? My downmixes sound just fine to me. Just the center will be louder than standard. And also, what level would the LFE get mixed in at? I wish I wouldn't have gotten rid of a lot of things I mixed already. Just to try out those levels.

Hmm. I just took 0.2612/0.3694 and it is ~ 0.707... the sin of 45°. I think the validity of that downmix is coming to play making its point and I will try that in the future.

[nurbs]

It decodes, increases precision to 64 bit, resamples, downmixes and decreases the bitdepth. FYI the order of most of the steps is listed in the log. No idea if the second downmix is "optimal" for normal stereo, but it is what is usually being used around here. No idea about the LFE either.

[Boulder]

I've been having a problem with eac3to and NeroAACEnc with later versions of eac3to. After encoding the decoded WAV, the log says that NeroAACEnc seems to be stuck (but I've no clue as to why) and it starts to encode the file again. I don't remember at which point the problem started to occur but it hasn't been there for long.

eac3to v3.24
command line: c:\utils\eac3to\eac3to.exe "e:\temp\dvd-rip\star trek tng\4x17 T81 3_2ch 384Kbps DELAY 0ms.ac3" "f:\temp\captures\tng_4x17_audio.m4a" -quality=0.42 -normalize -down2
------------------------------------------------------------------------------
AC3, 5.1 channels, 0:43:41, 384kbps, 48kHz, dialnorm: -27dB
Disabling DRC for Nero (E-)AC3 decoding...
Removing AC3 dialog normalization...
Decoding with DirectShow (Nero Audio Decoder 2)...
DirectShow reports 5.1 channels, 24 bits, 48kHz
Downmixing multi channel audio to stereo...
Writing WAV...
Creating file "f:\temp\captures\tng_4x17_audio.m4a.pass1.wav"...
Starting 2nd pass...
Reading WAV...
Reducing depth from 64 to 32 bits...
Encoding AAC <0.42> with NeroAacEnc...
Applying 3,6dB gain...
The original audio track has a constant bit depth of 64 bits.
The processed audio track has a constant bit depth of 32 bits.
The Nero AAC encoder seems to be stuck... <ERROR>
[NeroAacEnc] Processed 0 seconds...
[NeroAacEnc] Processed 1 seconds...
[NeroAacEnc] Processed 2 seconds...
[NeroAacEnc] Processed 3 seconds...
[NeroAacEnc] Processed 4 seconds...
[NeroAacEnc] Processed 5 seconds...
[NeroAacEnc] Processed 6 seconds...
[NeroAacEnc] Processed 7 seconds...
[NeroAacEnc] Processed 8 seconds...
[NeroAacEnc] Processed 9 seconds...
[NeroAacEnc] Processed 10 seconds...
[NeroAacEnc] Processed 11 seconds...
[NeroAacEnc] Processed 12 seconds...
[NeroAacEnc] Processed 13 seconds...
[NeroAacEnc] Processed 14 seconds...
[NeroAacEnc] Processed 15 seconds...
[NeroAacEnc] Processed 16 seconds...
[NeroAacEnc] Processed 17 seconds...
[NeroAacEnc] Processed 18 seconds...
[NeroAacEnc] Processed 19 seconds...
[NeroAacEnc] Processed 20 seconds...
[NeroAacEnc] Processed 21 seconds...
.
.
.
.
[NeroAacEnc] Processed 2531 seconds...
[NeroAacEnc] Processed 2532 seconds...
[NeroAacEnc] Processed 2533 seconds...
[NeroAacEnc] Processed 2534 se
Aborted at file position 2012946500. <ERROR>

[ramicio]

I have been getting the same thing lately, and randomly. I cannot say for what version. I only started using the Nero encoder on the newest version.

[jasonwc]

Is there any plan to extract chapter information from MKVs? Currently, eac3to can extract video, audio, and subtitle formats, but it doesn't show or extract the chapter data.

[jasonwc]

madshi,

I did some more testing and I figured out why I thought the delay was 24 ms while others said it was 21ms. We're both right. We were just counting differently. I assumed that if you simply calculated the difference in length between the DTS-HD MA --> WAV output and the Source PCM output, you would find the delay, since I assumed it was just added that number of samples of digital silence to the beginning of the track.

In fact, it seems more complicated but the bottom line is that the delay information is contained in the "Codec delay" tag which can be found in the DTS-HD MA header, readable by DTS-HD Streamtools. All BD sourced DTS-HD MA tracks lack this tag, and therefore decode properly with no delay. "Raw" DTS-HD MA files created with MAS have a Codec Delay of 1024 samples. A DTS frame is 512 samples, so the delay is always 2 DTS frames, or 21.33ms (assuming 48 Khz source). eac3to need merely read the DTS-HD MA header to properly decode the track. Unfortunately the Arcsoft DTS decoder does not strip the first 2 DTS frames as instructed by the header. In contrast, DTS Streamplayer does. Thus, eac3to ought to either read the DTS-HD MA header to detect the codec delay, or, if that is not possible, simply strip the first 2 DTS frames from any raw DTS-HD MA track.


I tested this way using eac3to 3.24 - Source (TrueHD) ---> WAVS ---> DTS-HD MA ---> WAVS
I compared the Center channel mono-wavs.

Original Source: 54:09.288 (155965840 samples)
DTS-HD MA --> WAV: 54:09.312 (155966976 samples)

Difference: 1136 Samples / 48,000 Samples/sec = 23.666 ms

I checked the length/# of samples in foobar2000 and Adobe Audition, and they matched. The DTS-HD MA --> WAV track is 23.666 ms longer than the source WAV.

However, when I checked the actual audio delay in Adobe Audition, I found the delay was actually only 21.35 ms.

Attached I have posted an Adobe Audition screenshot with 4 WAVs compared side-by-side. See
http://img823.imageshack.us/img823/1902/audition5.th.png (http://img823.imageshack.us/i/audition5.png/)

Wave 1: Source (TrueHD --> WAVS)
Wave 2: DTS-HD MA --> WAVS with -20ms delay
Wave 3: DTS-HD MA --> WAVS with -21ms delay
Wave 4: DTS-HD MA --> WAVS with -22 ms delay

The closest match is Wave3 (-21ms). However, the -21ms sample still appears to be behind by 0.35ms. I calculated this in two ways. First, I calculated the delay visually and saw that the difference was approximately 10:41.777 seconds - 10:41.77665 seconds, which is 0.00035 seconds, or 3.5 ms. I also counted the number of audio samples within the selection and found 17 (18 appear highlighted, but that's because Audition doesn't allow you to precisely select, and it went a bit too far to the right).

17 samples / 48,000 samples/sec = 0.354 ms
Total Delay = 21.35 ms

Thus, it appears that raw DTS-HD MA tracks encoded with the DTS-HD Master Audio Suite (Version 2.50.20) when decoded in eac3to using the Arcsoft DTS decoder, have an additional 23.66 ms in length, but only have a positive delay of 21.35 ms. I have no idea what is going on with the additional 2.3 ms of samples.

Both jj666 and I were able to replicate the same results using a source THD from the Dexter S04 BDs.

Source ---> WAVS ---> DTS-HD MA (MAS Encoder) ---> WAVS

DTS-HD MA WAVS v. Source WAVS:
Additional 23.66 ms in Length
Positive delay of 21.35 ms (appx)

As a DTS frame is 10.666 ms, it appears we were right that the delay is exactly 2 DTS frames, or 21.33 ms.

But it turns out all this testing was unnecessary. Here's the relevant portion of the DTS-HD MA header:

...

Source Samples : 155965840
Sample Rate : 48000Hz
Samples Per Frame : 512
Codec Delay : 1024
...

In other words, the delay can be calculated simply by reading the DTS-HD MA header, and from what we've seen it should always be exactly 2 DTS frames.

1024 samples / 48,000 samples/sec = 21.33 ms delay

So, all eac3to has to do is to read the DTS-HD MA header. DTS-HD MA tracks sourced from Blu-Rays do not have a "Codec Delay" tag in the header, and thus are decoded properly. In contrast, raw DTS-HD MA files produced with MAS do have such a header, and appear to always add a delay of 1024 PCM samples/2 DTS frames. The DTS Streamplayer reads the header and outputs accordingly. Arcsoft does not head the delay info, explaining the 21.33 ms delay in eac3to.

[jj666]

Madshi,

In addition to the above post, I also saw that a manual delay is ignored when doing a second pass to strip zero bytes (ie, eac3to test.thd test.lpcm -21ms will actually not apply the delay if a second pass is needed).

Cheers,

-jj-

[jasonwc]

It seems MAS always uses a codec delay of 2 DTS frames (21.33ms). At 48 Khz, the delay is 1024 samples, 2048 at 96 Khz, and 4096 at 192 Khz.

[marcio]

http://img833.imageshack.us/img833/6417/eac3to.jpg

[Bard2]

Just to clarify: is "demuxing" multichannel WAV to mono WAVs trough eac3to using commandline like this "eac3to source.wav demuxed.wavs" lossless?

[ramicio]

Just to clarify: is "demuxing" multichannel WAV to mono WAVs lossless?

Yes it is.