eac3to - audio conversion tool

[r0lZ]

Originally Posted by madshi

I'll need a sample. One which is complete enough so I can fully reproduce the incorrect listing.

OK, I'll try to find a 3D short that can serve as an example. Currently, I can't do much better than the sample I gave you. I don't know how to cut the SSIF and the two M2TS files at the right position.

[madshi]

I don't think it has to be the "right" position. It just has to be big enough to allow eac3to to detect the video track properties. Probably something like 50MB for the first SSIF and 25MB for the first m2ts file would work ok. If the playlist contains multiple m2ts files, and the first one is smaller than 50MB, leave the first m2ts/ssif file untouched and shorten the 2nd one so that the overall sum is 25MB/50MB. Something like that. You can always test this right away on your PC: If eac3to reproduces the problem with your cut down sample, then you've done well and you can zip/upload it.

[r0lZ]

OK. But I don't understand why you need the video files. The flag is in the MPLS file only, and it should be sufficient to read it to know that the 2 views are inverted. Anyway, I am preparing a sample...

[Stereodude]

Originally Posted by Boulder

There is something to extract, for example the latest version of mkvmerge can get the embedded AC3 track for you.

Please explain to me how a tool can extract something that isn't there. THD has no core. THD is packed with an AC3 track on Blu-ray because the specs require it and some people call that the "core", but THD doesn't have a core. THD can be separated from the "core" (the ac3 packed with it) and still be decoded. For example, HD-DVD had THD with no AC3 track packed along side of it.

[madshi]

Originally Posted by r0lZ

OK. But I don't understand why you need the video files. The flag is in the MPLS file only, and it should be sufficient to read it to know that the 2 views are inverted. Anyway, I am preparing a sample...

The reason is that there's a difference between implementing something with or without the ability to test it. I tried to implement it without being able to test it, and as you reported, my implementation only half worked. I don't know why it doesn't fully work, I thought it would. That's why I need the sample, so I can analyze better why it fails to work completely. If you're a dev you should know that it's important to be able to test something, instead of just implementing something "blindly". If you're not a dev, then that's ok, you probably couldn't know...

[r0lZ]

I'm a dev, and I know that if I get the right flag, it is easy to simply swap the left and right strings in the output. But I understand your point.

I did 3 samples, but none are perfect. When I cut 50MB of the SSIF and respectively 30 and 20 MB of the AVC and MVC M2TS files, eac3to can list the streams when using the "1)" argument (with the full parsing of the video file), but it lists only the chapters when used without the "1)" argument. I don't understand why, so I have made a new sample with file sizes twice as big. Same result!

My third test is completely different: I have taken a short menu file (one minute long) with the standard left/right order of the views, and I have patched the MPLS with an hex editor to set the base view R flag. IMO, my patch should be sufficient to invert the views, but I don't know if there are other differences regarding the left/right views order. Now, eac3to works exactly as described in my post above: correct without the "1)", but wrong with it. It lists all streams in both cases (without the subpics in the first case, but it's normal.) The total size of that sample is 621MB. A bit too much, but I should be able to post it somewhere. Unfortunately, I don't have any 3D clip with the views inverted short enough to be uploaded somewhere, so I had to use that trick.

Do you want the first sample, that doesn't show the video streams without the 1) argument, or the second one, fully working but big and not "official"?

[Boulder]

Originally Posted by Stereodude

Please explain to me how a tool can extract something that isn't there. THD has no core. THD is packed with an AC3 track on Blu-ray because the specs require it and some people call that the "core", but THD doesn't have a core. THD can be separated from the "core" (the ac3 packed with it) and still be decoded. For example, HD-DVD had THD with no AC3 track packed along side of it.

I don't know, you would have to ask Mosu about it.

Originally Posted by mkvmerge changelog

2015-02-10 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: mkvmerge will now recognize TrueHD+AC3 files as consisting of two tracks. Instead of always dropping the AC3 part the user can simply select which tracks to keep. Part of the implementation of #1107.

[r0lZ]

Originally Posted by r0lZ

When I cut 50MB of the SSIF and respectively 30 and 20 MB of the AVC and MVC M2TS files, eac3to can list the streams when using the "1)" argument (with the full parsing of the video file), but it lists only the chapters when used without the "1)" argument.

Sorry, I didn't know that it is necessary to include the CLIPINF directory as well. I have added it in the first sample, and now eac3to can lists the streams even without the 1) argument. I will upload that sample...

[EDIT] Sample uploaded. See the bug tracker for the link.

[szabi]

Originally Posted by Music Fan

With TSmuxer, check "downconvert True HD ..." in track options and choose demux as output format. Don't worry, that's an extraction, not a conversion (encoding).

I tried, but did not worked.

[Q-the-STORM]

thanks madshi for the new version... I hope you have a bit more time in the future and replace aften with libav/ffmpeg for ac3 encoding :P

Originally Posted by Boulder

I don't know, you would have to ask Mosu about it.

alright..

on the BD there is a TrueHD track with an embedded AC3 track...
those 2 tracks can both work completely independently... you can "extract" the AC3 track and it will work without TrueHD and you can "extract" the TrueHD Track and it will work without the AC3 Track....

the AC3 Track is embedded for backward compatibility with receivers WITHOUT having to change to another audio track...
so people can bitstream it and if the receiver can't decode TrueHD, it can fall back on AC3....

BUT the big difference to DTS is, that DTS-HD will not work without the DTS core... that's why on DTS it's called a core and on TrueHD it's called embedded... on DTS-HD you can extract the core, but you can't have DTS-HD wihtout the core... DTS-HD is simply the Core + extra information to make it lossless (on DTS-HD MA at least)...

TrueHD is lossless all on it's own, it doesn't need the AC3 track at all.

so in eac3to you have the option to demux thd, ac3 or thd+ac3...
all of those options will give you one file...

and here's the thing:
the m2ts (Blu-ray) container supports embedded tracks, the matroska container doesn't!
so if you want to have a TrueHD track in mkv, you HAVE TO remove the embedded track!

in the past, mkvmerge did exactly this... They just removed the embedded AC3 track and muxed the TrueHD track only.
but there are people that want the AC3 track as well, they would have to extract the embedded AC3 track with eac3to or tsmuxer or any other tool seperately and then mux it.

Now mkvmerge eliminated this step. Instead of simply removing the embedded AC3 track, it gives the option to mux it in as a SEPERATE audio track. if you now bitstream the TrueHD track, your receiver does not have to option to fall back on AC3 anymore, you have to select the seperate ac3 track in your player...


now if you have a mkv file with a trueHD track, or you have extracted the TrueHD track with eac3to (and didn't use thd+ac3 extension) then there is no embedded AC3 Track anymore. If you want to get an AC3 track from it, it HAS to be encoded...

[Snowknight26]

Originally Posted by madshi

Ooops, too late. Why didn't you create a bug tracker entry for this, then I might have looked at it. Now 3.28 is already done.

Anyway, are you sure that the real playlist and the one selected by eac3to are really different? Often there are multiple duplicates, and eac3to simply selects one "by random".

Aside from the different chapters they're identical.

Thanks for the new version regardless!

[madshi]

Originally Posted by r0lZ

I'm a dev, and I know that if I get the right flag, it is easy to simply swap the left and right strings in the output.

Well, it's not as easy as it sounds, because when doing "1)" eac3to goes a totally different way. It analyzes the m2ts files and mostly disregards the mpls information. Only later the m2ts parsing results and the mpls information is tried to be tied together again. This is a quite complicated process (eac3to even tries to automatically find a matching playlist even if you manually entered a number of m2ts files instead of the mpls), and that's why it's not that easy to implement this without being able to test it.

Originally Posted by Snowknight26

Aside from the different chapters they're identical.

Oh. It's possible that eac3to isn't comparing the chapters when deleting "duplicate" playlists from the listing.

[Stereodude]

Originally Posted by szabi

I tried, but did not worked.

That's because your TrueHD has no embedded AC3 track to extract. No tool can extract what isn't there. You can only extract AC3 from TrueHD+AC3 tracks.

[tebasuna51]

- Test decoding 5 standard TrueHD samples with different number of channels, bitdepth and samplerate:
the eac3to v3.27 and v3.28 output are bit-identical.

- Test decoding 3 TrueHD Atmos samples (I don't have many samples):
the eac3to v3.28 output and a recent ffmpeg are bit-identical.

- Test over 2 TrueHD Atmos samples extracting the AC3 core:
the eac3to v3.28 output is better than tsMuxeR extraction because tsMuxeR add extra garbage at end of the AC3.

[madshi]

Thanks for the tests!

[jpsdr]

Originally Posted by madshi

Have you bothered to read the announcement post? Read the last sentence again.

You're absolutely right, i'm stupid i didn't see it, all my sincere appologies !

Thanks for your work.

[Overdrive80]

Hi, thanks for updated. For any reason, I never get update haali version according to eac3to (I install last version from http://haali.su/mkv/):

"Haali Matroska Muxer (2013-04-14) is installed
There's a new version (2013-06-23) available
http://haali.net/mkv"


Thanks
Any fix or workaround?

[Sparktank]

Originally Posted by Overdrive80

"Haali Matroska Muxer (2013-04-14) is installed
There's a new version (2013-06-23) available

IIRC, they're the same code.
The 4-14 was the beta version that was tested before releasing it as official (06-23).
The date is the only thing truly different as everything else remained identical in the official release.
For some reason the Haali site never really updated because I downloaded their binary and never got the 06-23 date to silence eac3to.

I use K-Lite Codec Pack, and they've since updated to the binary with the most recent date, just to please eac3to users.
Or OCD users.

I went weeks, maybe months before I even noticed KLCP updated the cosmetic date.

Somone might have a link to a binary with the date eac3to expects.
Or whatever codec pack you're using (if any), you could ask them to update their installer.

[mariner]

Originally Posted by madshi

eac3to v3.28 released

http://madshi.net/eac3to.zip

* fixed: #001: different number of frames for left and right eye
* fixed: #061: valid silence edit was sometimes rejected
* fixed: #067: error messages were not available to GUIs
* fixed: #086: left/right eye information was inverted in some 3D Blu-Rays
* fixed: #131: TrueHD Atmos streams could not be demuxed or decoded
* fixed: #243: ArcSoft DTS decoder crash made eac3to crash, too
* downStereo: added 0.7071 factor for surround/back channels (ITU-R BS.775-3)
* downStereo/Dpl: using 0.5 instead of 0.7071 factor for LFE (ITU-R BS.775-3)

Please note that some of these changes have been implemented without a lot of testing. So it would be great if you guys could double check things, especially the changes, to make sure they really work as intended. Also please make sure TrueHD decoding still works losslessly, as usual (even for non-Atmos tracks). I've hacked Atmos "support" into the old ffmpeg version I've been using for years, so I wouldn't have to update to the latest ffmpeg version. Don't have much time atm, so I tried to do the most important stuff with the least amount of work.

Greetings madshi. Many thanks for the update.

[howzz]

in the process of trying to find ways to speedup the demuxing, muxing process, i came across one of the change logs that was mentioned here. i think it was version 2+ "improvement of the speed performance of the muxing process", or something that nature.

i am a long time user of Ripbot264. recently i moved my working folder from a secondary HDD to a primary SSD and noticed the initial demuxing process in ripbot went from 23 mins to 11 mins. i was looking for more ways to improve the speed of the demux and realized by moving to an even faster SSD made no difference. it got me thinking whether the DDR3 RAM speed is the factor, or is it the software ie. hali/eac3to etc..

According to Resource Monitor, the eac3to process (during ripbot264 demuxing), is only reading at 50~60MB/s and writing the video.mkv stream at about the same speed. And by moving to an even faster SSD, the SSD utilization does not go up, in fact, it's well under 100%. CPU utilization is less than 5% so it's not really fully utilizing the full potential of the SSD, or the CPU. the only other hardware i can think of would be the RAM. but before i go out and upgrade from DDR3 1866 to DDR3 2600, i just want to make sure that it's not the software.

could someone shed some light on this subject? is it Hali's fault? or is it a hardware limiting factor? my rig is i7 @4.8ghz with Crucial SSD M4 and Crucial MX100, DDR3 1866 16GB. what can i do to farther improve the demuxing speed.

thanks so much!