eac3to - audio conversion tool

[rica]

Originally Posted by Jaja1

Use the command "eac3to" without any options from anywhere in the blu-ray folder and you'll get what you want.

Hey, thanks. Easy.

G:\>eac3to\eac3to.exe G:\HDBACKUPS\CETK   (enter)

1) 00056.mpls, 2:17:14
   [0+2+6+8+9+12+13+15+16+19+20+21+24+25+26+28+118+119+32+33+34+37+39+40+42+43+45+46+49].m2ts
   - h264/AVC, 1080p24 /1.001 (16:9)
   - TrueHD, English, multi-channel, 48khz
   - DTS Master Audio, English, multi-channel, 48khz

2) 00054.mpls, 2:14:45
   [0+1+6+7+9+10+13+14+16+17+20+22+24+25+26+27+118+117+32+33+34+37+38+40+41+43+44+46+47].m2ts
   - h264/AVC, 1080p24 /1.001 (16:9)
   - TrueHD, English, multi-channel, 48khz
   - DTS Master Audio, English, multi-channel, 48khz

3) 00055.mpls, 2:12:30
   [0+2+6+8+9+11+13+15+16+18+20+21+24+26+28+118+119+32+36+37+39+40+42+43+45+46+48].m2ts
   - h264/AVC, 1080p24 /1.001 (16:9)
   - TrueHD, English, multi-channel, 48khz
   - DTS Master Audio, English, multi-channel, 48khz

And it confirms that eac3to and bdinfo are agree:




__ _ __ _

[rica]

But the question is where these other three mpls files are?
eac3to just shows:

00056
00054 and
00055

while bdinfo shows:
00056
00054
00055
00225
00226
00101

Then where are the remainings ?
What title numbers do they have?




_ _ _ _ _

[nautilus7]

You can easily find what is the content of each playlist file by playing the corresponding m2ts files in a media player.

eac3to doesn't show any playlist shorter than 15 minutes. That applies to HD DVDs and Blu-ray Discs as well.

[rica]

Originally Posted by nautilus7

You can easily find what is the content of each playlist file by playing the corresponding m2ts files in a media player.

eac3to doesn't show any playlist shorter than 15 minutes. That applies to HD DVDs and Blu-ray Discs as well.

OK, thanks a lot; i've been about to get lost between 300 pages.

EDIT: Everyday i learn a new tip/trick; that is why i love eac3to as well.

[rica]

OK guys,
another history of mine:

today i loaded 00056.mpls to TSMuxer and i got an m2ts which including true hd and dts-hd ma.
I left true hd since eac3to doesn't correct the gaps and i got dts-hd ma corrected in second-pass; no problem.
Then as advised i directly tried to transmit true HD to PCM.
This is what i got:

:\>eac3to\eac3to.exe C:\Users\rica\Desktop\CETK.m2ts 2: C:\HD\audio.pcm

M2TS, 1 video track, 2 audio tracks, 2 subtitle tracks, 2:17:14
1: h264/AVC, 1080p24 /1.001 (16:9)
2: TrueHD/AC3, English, 5.1 channels, 48khz, -41ms
3: DTS Master Audio, English, 5.1 channels, 24 bits, 48khz, -41ms
4: Subtitle (PGS), English
5: Subtitle (PGS), Turkish
[a02] Extracting audio track number 2...
[a02] Extracting TrueHD stream...
[a02] Decoding with libav/ffmpeg...
[a02] Applying RAW/PCM delay...
[a02] Swapping endian...
[a02] Remapping channels...
[a02] Creating file "C:\HD\audio.24bit.pcm"...
[a02] This audio track contains more than 16 bits of information.
[libav] Lossless check failed - expected f9, calculated b2
[libav] Lossless check failed - expected a8, calculated d9
[libav] Lossless check failed - expected 2e, calculated a7
[libav] Lossless check failed - expected fb, calculated 35
[libav] Lossless check failed - expected 9d, calculated e
[libav] Lossless check failed - expected b7, calculated aa
[libav] Lossless check failed - expected 3e, calculated 4c
[libav] Lossless check failed - expected a7, calculated a6
[libav] Lossless check failed - expected 61, calculated 5e
[libav] Lossless check failed - expected 77, calculated 78
[libav] Lossless check failed - expected 94, calculated 9e
[libav] Lossless check failed - expected 38, calculated a1
[a02] This audio track has a constant bit depth of 24 bits.
[a02] Audio overlaps for 5ms at playtime 1:03:58.
[a02] Audio overlaps for 5ms at playtime 2:11:04.
[a02] The audio file was demuxed without making use of the gap/overlap informati
on.
[a02] Please rerun the same eac3to command line. That will correct the gaps/over
laps.
Video track 1 contains 197424 frames.
eac3to processing took 20 minutes, 17 seconds.
Done.

C:\>eac3to\eac3to.exe C:\Users\rica\Desktop\CETK.m2ts 2: C:\HD\audio.pcm

M2TS, 1 video track, 2 audio tracks, 2 subtitle tracks, 2:17:14
1: h264/AVC, 1080p24 /1.001 (16:9)
2: TrueHD/AC3, English, 5.1 channels, 48khz, -41ms
3: DTS Master Audio, English, 5.1 channels, 24 bits, 48khz, -41ms
4: Subtitle (PGS), English
5: Subtitle (PGS), Turkish
Audio gap description file detected, will be used for processing...
[a02] Extracting audio track number 2...
[a02] Extracting TrueHD stream...
[a02] Decoding with libav/ffmpeg...
[a02] Applying RAW/PCM delay...
[a02] Swapping endian...
[a02] Remapping channels...
[a02] Realizing RAW/PCM gaps...
[a02] Creating file "C:\HD\audio.24bit.pcm"...
[a02] This audio track contains more than 16 bits of information.
[libav] Lossless check failed - expected f9, calculated b2
[libav] Lossless check failed - expected a8, calculated d9
[libav] Lossless check failed - expected 2e, calculated a7
[libav] Lossless check failed - expected fb, calculated 35
[libav] Lossless check failed - expected 9d, calculated e
[libav] Lossless check failed - expected b7, calculated aa
[libav] Lossless check failed - expected 3e, calculated 4c
[libav] Lossless check failed - expected a7, calculated a6
[libav] Lossless check failed - expected 61, calculated 5e
[libav] Lossless check failed - expected 77, calculated 78
[libav] Lossless check failed - expected 94, calculated 9e
[libav] Lossless check failed - expected 38, calculated a1
[a02] This audio track has a constant bit depth of 24 bits.
Video track 1 contains 197424 frames.
eac3to processing took 33 minutes, 20 seconds.
Done.

EDIT:And this time i've been trying to correct (remove overlaps/gaps) pcm from the main source (restarted the application)

C:\>eac3to\eac3to.exe G:\HDBACKUPS\CETK\ 1) 3: G:\HDBACKUPS\audio.pcm
M2TS, 1 video track, 2 audio tracks, 20 subtitle tracks, 2:17:13
1: Chapters, 20 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: TrueHD/AC3, English, 5.1 channels, 48khz
4: DTS Master Audio, English, 5.1 channels, 24 bits, 48khz
5: Subtitle (PGS), English
6: Subtitle (PGS), English
..........

[a03] Extracting audio track number 3...
[a03] Extracting TrueHD stream...
[a03] Decoding with libav/ffmpeg...
[a03] Swapping endian...
[a03] Remapping channels...
[a03] Creating file "G:\HDBACKUPS\audio.24bit.pcm"...
[a03] This audio track contains more than 16 bits of information.
[a03] This audio track has a constant bit depth of 24 bits.
[a03] Audio overlaps for 5ms at playtime 0:58:47.
[a03] Audio overlaps for 5ms at playtime 1:34:34.
[a03] The audio file was demuxed without making use of the gap/overlap informati
on.
[a03] Please rerun the same eac3to command line. That will correct the gaps/over
laps.
Video track 2 contains 197424 frames.
eac3to processing took 29 minutes, 32 seconds.
Done.

C:\>eac3to\eac3to.exe G:\HDBACKUPS\CETK\ 1) 3: G:\HDBACKUPS\audio.pcm
M2TS, 1 video track, 2 audio tracks, 20 subtitle tracks, 2:17:13
1: Chapters, 20 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: TrueHD/AC3, English, 5.1 channels, 48khz
4: DTS Master Audio, English, 5.1 channels, 24 bits, 48khz
5: Subtitle (PGS), English
6: Subtitle (PGS), English
........

Audio gap description file detected, will be used for processing...
[a03] Extracting audio track number 3...
[a03] Extracting TrueHD stream...
[a03] Decoding with libav/ffmpeg...
[a03] Swapping endian...
[a03] Remapping channels...
[a03] Realizing RAW/PCM gaps...
[a03] Creating file "G:\HDBACKUPS\audio.24bit.pcm"...
[a03] This audio track contains more than 16 bits of information.
[a03] This audio track has a constant bit depth of 24 bits.
Video track 2 contains 197424 frames.
eac3to processing took 39 minutes, 33 seconds.
Done.

Sure, those pcm files have to be re-processed by Pcm2Tsmu (by tebasuna51) so as to be recognized by TSMuxer:

C:\>Pcm2TSmu13\Pcm2Tsmu C:\HD\audio.pcm C:\HD\audio_out.pcm -i 24

_ _ ___

[rica]

All those experiences teach us again:
Remuxing of BDs including multiple m2ts files with TSMuxer doesn't correct or remove the gaps/overlaps; so they have to be re-processed by eac3to,
eac3to can not correct gaps/overlaps of True HD files on those BDs, so they have to be transmitted to any other uncompressed or lossless files like pcm or wav or flac.
Created re-encoded files as pcm have to be re-processed with pcm2tsmu again so as to be recognized by TSMuxer.

[Greif]

@madshi: what programming language is eac3to written in? I'm also curious as to the available hooks into the code. Is everything done via StdIn/StdOut?

[madshi]

Originally Posted by nautilus7

There's a problem with AGM files.

DTS Pro Encoder will accept all AGM files made from DTS-HD Master Audio tracks, but will reject every single AGM file made from TrueHD tracks

Originally Posted by xkodi

if the decoded TrueHD track is less than 4GB the problem is not there.

Thanks, will check that out.

Originally Posted by Mercury_22

Can you add MKV to "Supported source formats" ? PLEASE !

Maybe some day. But probably not anytime soon.

Originally Posted by zyrill

Did anybody ever experience the following error and has found a workaround?

[a05] Removing TrueHD dialog normalization...
[a05] Decoding with libav/ffmpeg...
[libav] Substream 0 checksum failed
[libav] No restart header present in substream 1.
[a05] The libav decoder reported an error while decoding.
Aborted at file position 81920.

Apparently the sourcefile has some errors and the decoder crashes over it.

Correct. And your best bet is to rerip the disc. Should be no problem if you actually own the disc. Which you should...

Originally Posted by nautilus7

eac3to Shoot.'Em.Up.2007.Blu-ray.flac" shoot.em.up.aac
FLAC, 7.1 channels, 1:26:32, 24 bits, 5095kbps, 48khz
NeroAacEnc only supports 6 channels. Will mix the surround channels.

Nero supports 7.1 encoding.

Yes, the new version (which is just a few days old) does. The old version did not.

Originally Posted by nautilus7

madshi, it would be nice if eac3to displays the profile of the AAC file (LC, HE, HEv2), runtime and the bitrate even in vbr tracks, like it's done in flac.

I don't know how to get this information. For FLAC it's easy cause all the info is in the header. But raw AAC streams don't have a header like that (AFAIK).

Originally Posted by ACrowley

WOW ! Nero 9 Decoders are working outside Showtime!

Nice! Can you create an XML graph (GraphEdit) and post the XML text here, please?

Originally Posted by Atak_Snajpera

Nope Sometimes video contains gaps as well

That's the first Blu-Ray I've seen which has video overlaps in it! Do you see any difference in the video playback smoothness when you let eac3to fix vs. not fix the overlaps?

Originally Posted by Joniii

Which Blu-ray tracks needed channel remapping, was it only PCM?

If you let eac3to do the demuxing/transcoding you don't need to worry about things like that.

Originally Posted by baudi

How can I convert a 25fps audio track to exactly 24fps.

Currently not with eac3to. It's on my to do list.

Originally Posted by jwdaigle

Hi, sorry if this question has already been asked

It has. Please search for "seekToIFrames".

Originally Posted by Greif

@madshi: what programming language is eac3to written in? I'm also curious as to the available hooks into the code. Is everything done via StdIn/StdOut?

eac3to is written in Delphi. What do you mean with "hooks into the code"?

[madshi]

eac3to v2.66 released

http://madshi.net/eac3to.zip

* fixed AGM creation for files bigger than 4GB
* changed eac3to to allow AAC encoding with 7.1 channels (for new Nero encoder)
* added support for Nero's new AAC Encoder download URL
* lowered volume of error/success sounds
* when there are 2 similar playlists the one with less chapters is ignored now

[nautilus7]

Thanks madshi.

btw any fix for the mkvtoolnix update check?

[madshi]

Originally Posted by nautilus7

btw any fix for the mkvtoolnix update check?

What's wrong with it? Seems to work fine for me.

[nautilus7]

Well, it always says there's a new beta available even if i have the newest version already installed. This happens with all versions of eac3to.
And i just saw that the date of the mkvtoolnix version is not displayed correctly with v2.66, while it did with older versions.

eac3to -test
Nero Audio Decoder (Nero 7 or older) works fine
ArcSoft DTS Decoder (1.1.0.0) works fine
Sonic Audio Decoder (4.3.0.169) works fine
Haali Matroska Muxer (2008-03-29) is up to date
Nero AAC Encoder (1.3.3.0) is up to date
Surcode DTS Encoder (1.0.29.0) is installed
MkvToolnix (2.3.0.0, 2008--04) is up to date
  There's a new beta version (2.3.0.0, 2008-10-05) available
  http://www.bunkus.org/videotools/mkvtoolnix/win32/pre

[madshi]

Originally Posted by nautilus7

Well, it always says there's a new beta available even if i have the newest version already installed. This happens with all versions of eac3to.

eac3to does not OCR the message box of the GUI, obviously, to get the version number. Instead eac3to captures what "mkvmerge --version" says. Sometimes that information is not correct or sometimes mkvmerge is simply older than the GUI. If that is the case there's nothing I can do about it. I won't add OCR to eac3to just to get the version number/date of the GUI!! It can happen that Mosu recompiled only the GUI or only mkvmerge in a new beta build. Since eac3to can only get the version number of mkvmerge, there is potential for incorrect reports. Can't do anything about that, unless Mosu adds programatically readable version information to the GUI, too.

Originally Posted by nautilus7

And i just saw that the date of the mkvtoolnix version is not displayed correctly with v2.66, while it did with older versions.

That's a bug in eac3to. It doesn't understand "Oct" as a month. Will be fixed in the next build.

[rebkell]

Madshi, would it be possible on the discontinuities to also print the frame number in the message, in addition to the file pos?

[madshi]

Originally Posted by rebkell

Madshi, would it be possible on the discontinuities to also print the frame number in the message, in addition to the file pos?

That'd be hard to do because the layer of processing which detects the discontinuities doesn't know anything about audio/video frames...

[rebkell]

Originally Posted by madshi

That'd be hard to do because the layer of processing which detects the discontinuities doesn't know anything about audio/video frames...

Ok, just thought I'd ask, I have them sometimes on the Hauppauge HD-PVR caps and it's difficult to figure out where the discontinuities are happening. I suspect most happen during commercials, but you never know.

[madshi]

Originally Posted by rebkell

Ok, just thought I'd ask, I have them sometimes on the Hauppauge HD-PVR caps and it's difficult to figure out where the discontinuities are happening. I suspect most happen during commercials, but you never know.

If you ask eac3to to ignore the discontinuities, does demuxing/transcoding succeed then? And do you then get any audio or video corruptions during playback? Just wondering whether these discontinuities are the result of a buggy broadcasting setup. Or whether there is real corruption in the data?

[Jaja1]

Hi Madshi,

You probably missed my post, so here is my question again. What does the message "Lossless check failed" mean? And is the resulting DTS track in someway influenced by this?

eac3to v2.65
command line: eac3to 1) 2:i:\M.mkv 3:i:\M.dts 8:i:\M.1.sup 9:i:\M.2.sup
------------------------------------------------------------------------------
M2TS, 1 video track, 5 audio tracks, 10 subtitle tracks, 1:25:55
1: Chapters, 20 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: TrueHD/AC3, English, 5.1 channels, 48khz, dialnorm: -27dB
4: AC3, French, 5.1 channels, 640kbps, 48khz, dialnorm: -27dB
5: AC3, Spanish, 5.1 channels, 640kbps, 48khz, dialnorm: -27dB
6: AC3, Portuguese, 5.1 channels, 640kbps, 48khz, dialnorm: -27dB
7: AC3, English, 2.0 channels, 192kbps, 48khz, dialnorm: -27dB
8: Subtitle (PGS), English
9: Subtitle (PGS), English
10: Subtitle (PGS), French
11: Subtitle (PGS), Spanish
12: Subtitle (PGS), Portuguese
13: Subtitle (PGS), English
14: Subtitle (PGS), French
15: Subtitle (PGS), Spanish
16: Subtitle (PGS), Portuguese
17: Subtitle (PGS), English
[v02] Extracting video track number 2...
[a03] Extracting audio track number 3...
[s08] Extracting subtitle track number 8...
[s09] Extracting subtitle track number 9...
[a03] Extracting TrueHD stream...
[a03] Removing TrueHD dialog normalization...
[a03] Decoding with libav/ffmpeg...
[a03] Writing WAVs...
[v02] Muxing video to Matroska...
[a03] Creating file "i:\M.R.wav"...
[a03] Creating file "i:\M.L.wav"...
[a03] Creating file "i:\M.C.wav"...
[a03] Creating file "i:\M.SR.wav"...
[a03] Creating file "i:\M.SL.wav"...
[a03] Creating file "i:\M.LFE.wav"...
[s09] Creating file "i:\M.2.sup"...
[s08] Creating file "i:\M.1.sup"...
[libav] End of stream indicated
[libav] Lossless check failed - expected 0, calculated 8b
[a03] This audio track has a constant bit depth of 24 bits.
Encoding DTS <1536kbps> with Surcode...
Found Surcode DTS Encoder version 1.0.21.0.
Surcode encoding successfully started. Please wait...
Closing Surcode...
Added fps value to MKV header.
Video track 2 contains 123591 frames.
eac3to processing took 27 minutes, 38 seconds.
Surcode encoding took 13 minutes, 18 seconds.
Done.

[rebkell]

Originally Posted by madshi

If you ask eac3to to ignore the discontinuities, does demuxing/transcoding succeed then? And do you then get any audio or video corruptions during playback? Just wondering whether these discontinuities are the result of a buggy broadcasting setup. Or whether there is real corruption in the data?

They seem to vary, I recorded Sanctuary the other night on SciFi and eac3to reported 2 discons one at
3518061672
3518061860
and another at
7045026084
7045025896

on the rerun the first set at 3518061572 were the same and thethe ones around the 7GB mark it reported them in reverse order:
7045025895
7045026084

I muxed the audio you repaired back in and the first one which I'm assuming was the same as an audio gap of 750ms reported at 54:39 didn't appear to have any problems and the audio went out of sync.

You also reported an audio gap of 745ms at 1:49:07, which would probably coincide with the discon at the 7GB mark, there was definitely a problem in that area in the original, because that was where muxing originally caused the audio/video to go out of sync, and 745ms seems probably about right.

[nautilus7]

Originally Posted by madshi

eac3to does not OCR the message box of the GUI, obviously, to get the version number. Instead eac3to captures what "mkvmerge --version" says. Sometimes that information is not correct or sometimes mkvmerge is simply older than the GUI. If that is the case there's nothing I can do about it. I won't add OCR to eac3to just to get the version number/date of the GUI!! It can happen that Mosu recompiled only the GUI or only mkvmerge in a new beta build. Since eac3to can only get the version number of mkvmerge, there is potential for incorrect reports. Can't do anything about that, unless Mosu adds programatically readable version information to the GUI, too.

That explains. OCR is not needed of course, it's not important at all. Thanks!