eac3to - audio conversion tool

[madshi]

TrueHD from BluRay has ac3 frames in it, right?
Correct.

So, if i run eac3to bluray.thd output.ac3 it will extract those frames. How can i encode a new ac3 from this trueHD track (using aften)?
You could theoretically run "eac3to bluray.thd bluray.wav" to decode the TrueHD track to wav and then you could convert the wav file to AC3 by using aften.exe (don't know right now if eac3to supports "WAV -> AC3").

But as honai already said, this doesn't really make sense. The AC3 frames in the combined AC3/TrueHD track should always sound better than any AC3 encoding you can do with Aften.

[idbirch2]

Hi madshi, any joy with that weird DTS file?

I've got a BluRay with a really weird DTS audio format. When I try and run eac3to on it I get:

DTS Master Audio, 3/1 channels, 24 bits, 48khz
This channel format is currently not supported.

[nautilus7]

The next bigger eac3to version will do that internally - and in a better quality compared to sox. Sox 13 at least is just rounding each sample - which is a bad idea for audio quality. eac3to will use proper TPDF ("Triangular Probability Density Function") dithering.Nice!

Why would you want to do that? It makes no sense. The embedded AC3 is already at 640kbps, you can't get better quality or higher bitrate with aften.

But as honai already said, this doesn't really make sense. The AC3 frames in the combined AC3/TrueHD track should always sound better than any AC3 encoding you can do with Aften.

Maybe i want to get an ac3 with lower bitrate than 640. So, i have to do it in two steps.

I understood why it's AC3/TrueHD: you mean trueHD with ac3 in it, where i thought that both EAC3 and TrueHD have AC3 frames.

[madshi]

Hi madshi, any joy with that weird DTS file?
I'm sorry that it takes so long. I haven't forgotten your weird DTS file. It's still lying around here waiting to be fixed. The problem is that I'm busy with the next bigger eac3to version. Most of eac3to will be totally rewritten. But my time is very limited. So I'd rather delay checking your weird DTS file until the new version is ready. Otherwise I'd had to fix the problem twice - once in the old/current version and once in the new version.

[madshi]

i thought that both EAC3 and TrueHD have AC3 frames.
E-AC3 does not have AC3 frames in it. It's a different format. So you cannot simply extract AC3 frames from E-AC3. Theoretically there is a way to partially decode E-AC3 and reencode as AC3 (which saves CPU time and also improves audio quality a bit), but only Dolby knows how that works. So for us there is no other way than to fully decode E-AC3 to PCM/RAW and then reencode to AC3.

[idbirch2]

No apology necessary, I hadn't been keeping up with the thread as much recently so wasn't aware of the complete re-write, best of luck with this, I'd be lost without eac3to!

[madshi]

wasn't aware of the complete re-write
Well, I didn't talk about it yet... ;)

[Thunderbolt8]

what will be the benefits of the re-writing? less work for yourself with future versions? will it be faster? or require less hardware requirements?

[madshi]

what will be the benefits of the re-writing?
The old eac3to source code began with about 100 lines of code and grew over time to about 3500 lines of code. Often, when a little simple tool grows over time into something much bigger and more complex, the source code mutates into some kind of monster. This is what happened to eac3to. So the main purpose of the rewrite is to clean up the source code. Doesn't sound very impressive, does it?

Well, fortunately, the rewrite will also have several performance and feature improvements. I feel safe to predict that you will not be disappointed! ;)

However, it will take at least 2 weeks until it's ready to go, maybe even longer. I only have a limited time available for work on eac3to.

[nautilus7]

I guess the ac3 decode feature wont be added... Have you done any progress in it?

Looking forward for the new version!

[madshi]

I guess the ac3 decode feature wont be added...
Sooner or later it might get added. But I don't know when.

Have you done any progress in it?
No. I'm investing all my time into the rewrite.

[Thunderbolt8]

However, it will take at least 2 weeks until it's ready to go, maybe even longer. I only have a limited time available for work on eac3to.
doesnt matter whether its 2 weeks or a little longer. looking forward for the improvements :)

[Thunderbolt8]

is it possible that eac3 tracks behave different from trueHD tracks delaywise?
what I mean is that I made a remux from the game HD DVD and kept the original eac3 audio track, because I can play it with sonic decoder 4.3 (even if it does apply drc or norm or what it was, doesnt matter). the track requires no delay at all. the funny thing is just, when I tried to apply the mathematical way and see it this also works for eac3 tracks, which had resulted in -60ms of delay that you could see it everytime (!) when someone speaks in that movie that this delay is too much and that the original state of no delay at all is correct. for other movies its often hard up to very hard to find out whether a movie needs +/- 100ms of delay or more or not. depending on the movie it can be hell. and in this case here now in really every scene it shows that the -60ms is not needed. each time someone opens his mouth it can be seen, whereas you mostly need to look for specific scenes for other movies delays.
is this just the movie or has it something to do with the attributes of eac3 tracks?

[madshi]

is it possible that eac3 tracks behave different from trueHD tracks delaywise?
what I mean is that I made a remux from the game HD DVD and kept the original eac3 audio track, because I can play it with sonic decoder 4.3 (even if it does apply drc or norm or what it was, doesnt matter). the track requires no delay at all. the funny thing is just, when I tried to apply the mathematical way and see it this also works for eac3 tracks, which had resulted in -60ms of delay that you could see it everytime (!) when someone speaks in that movie that this delay is too much and that the original state of no delay at all is correct. for other movies its often hard up to very hard to find out whether a movie needs +/- 100ms of delay or more or not. depending on the movie it can be hell. and in this case here now in really every scene it shows that the -60ms is not needed. each time someone opens his mouth it can be seen, whereas you mostly need to look for specific scenes for other movies delays.
is this just the movie or has it something to do with the attributes of eac3 tracks?
With the "mathematical" way you mean your way of comparing the runtime of the different tracks? I don't think that this is the "right" way to calculate the delay. Maybe it works for most current TrueHD discs, but IMHO that could change sooner or later. The "mathematical" correct would be the just compare the timestamps of the first audio and video packets. For most movies the first eac3 frame and the first video frame have the same timestamp. That means, no delay is needed at all. With many movies TrueHD seems to behave the same - but still it does need delay most of the time!! I don't know yet why this is the case.

[honai]

Probably mastering errors. I remember them from the "olden" days of DVD discs.

Seriously, most friends of mine couldn't even spot a 100ms delay, or care about it.

There are also cases of A-list titles (like Underworld from Concorde) where video is mastered at 23.976fps but audio at 24fps .

Like I said in another thread, most "engineers" at those studios don't really know what they're doing.

[madshi]

There are also cases of A-list titles (like Underworld from Concorde) where video is mastered at 23.976fps but audio at 24fps .
Are you serious!?!? Are you talking about the German Underworld Blu-Ray? Do you mean audio slowly drifts out of sync on that disc?

:eek:

[honai]

Yes, the German HD-DVD (not Blu-ray). Funny enough, it doesn't drift, but if you demux audio you'll notice that it's 7 seconds shorter than the indicated video length in the XPL and demuxed video. 7 seconds = difference between 24fps and 23.976fps for 2 hours. You won't notice the error, though, because basically the timestamps are correct and thus audio frames will be rendered at the right time.

[madshi]

Yes, the German HD-DVD (not Blu-ray). Funny enough, it doesn't drift, but if you demux audio you'll notice that it's 7 seconds shorter than the indicated video length in the XPL and demuxed video. 7 seconds = difference between 24fps and 23.976fps for 2 hours. You won't notice the error, though, because basically the timestamps are correct and thus audio frames will be rendered at the right time.
So if you demux audio and then remux audio and video into MKV audio drifts out of sync then?

[honai]

Well, I've used mkvmerge for remuxing and supplied a 23.976fps timecode file, and the result was in sync. I'm not exactly sure why, I've never fully understood the concept of how mkvmerge syncs v/a streams, but my guess is that either for video or audio some frames are simply skipped or repeated.

[madshi]

That doesn't sound to me like the audio was really mastered at 24.000. Maybe it's simply 7 seconds shorter than the video for whatever reason, but still mastered at 23.976?

[honai]

Nope, it really plays until the end of video.

Maybe I mixed video/audio up, and video is actually 7 seconds shorter than what the XPL and audio length indicate, I will look it up later.

[ACrowley]

Yes, the German HD-DVD (not Blu-ray). Funny enough, it doesn't drift, but if you demux audio you'll notice that it's 7 seconds shorter than the indicated video length in the XPL and demuxed video. 7 seconds = difference between 24fps and 23.976fps for 2 hours. You won't notice the error, though, because basically the timestamps are correct and thus audio frames will be rendered at the right time.


No honai...So far i know the HDDVD is "surely" 23.976FPs. Video and Audio

Maybe you mean the demuxed dtscore ?
Remember the dtscore is not sync (demuxed outside Container ) and with incorrect Runtime with the standard dts_ac3 Source.ax Filter.
And the difference was ~ 7sec . That would exactly explain your 7 sec difference on the demuxed dtscore :)

With Madshis Source Filter Mod its Ok..the "demuxed" dtscore plays at correct Runtime and its sync
So use Madshis modified DTS_AC3_DD+ Source Filter and take a new look, im pretty sure its 7 sec longer

[The_Keymaker]

Hello forum members,

I have released a new version of EAC3toGUI (v1.38) for your use.

Link: http://www.sendspace.com/file/v0fg69

Changes to the new version include:

1. - Added Horizontal scroll to destination File
2. - Added *.ac3 source file extension
3. - Source path now "remembered" after program closes

Remember, as with previous version of EAC3toGUI, you should place the program in same directory as eac3to.exe. If you decide to place EAC3toGUI in a different directory, you should specify the location of eac3to.exe using the settings menu option.

Please report any bugs and feel free to post comments.

@madshi, please upload the updated program to your link on page 1.

Regards,
The_Keymaker

[Nikos]

So far i know the HDDVD subtitles and chapters points is "surely" 24 fps.
Any explain?

[honai]

Ok, I looked it up again.

The video stream on the disc says runtime is 02:13:25:00.

<Title id="mainMovie" titleNumber="4" titleDuration="02:13:25:00" onEnd="black" displayName="Underworld" description="mainMovie">

The runtime of the extracted audio stream is 02:13:25:00.

The runtime of the extracted video stream at 23.976fps is 02:13:32:00.

The runtime of the remuxed MKV with timecode file at 23.976fps is 02:13:32:00.

Obviously something is wrong here, don't you think? ;)

[Chumbo]

Hello forum members,

I have released a new version of EAC3toGUI (v1.38) for your use.

Link: http://www.sendspace.com/file/v0fg69

Changes to the new version include:

1. - Added Horizontal scroll to destination File
2. - Added *.ac3 source file extension
3. - Source path now "remembered" after program closes

Remember, as with previous version of EAC3toGUI, you should place the program in same directory as eac3to.exe. If you decide to place EAC3toGUI in a different directory, you should specify the location of eac3to.exe using the settings menu option.

Please report any bugs and feel free to post comments.

@madshi, please upload the updated program to your link on page 1.

Regards,
The_Keymaker
Thank you for the changes. Here are my reports/comments:
1. - Added Horizontal scroll to destination File
Verified that it works. :)

2. - Added *.ac3 source file extension
Verified that it works. :)

3. - Source path now "remembered" after program closes
This one not working as expected even though you went beyond what I was asking. The "remembered" I was referring to is to just remember where the last folder was when you hit the Browse button, i.e., it would take you back to the last location you loaded a file from. Although what you came up with is even better, however, it's kinda buggy right now.

When I launched it the first time, it entered the path plus eac3to.exe, i.e., "d:\avutils\eac3to.exe" which immediately caused the invalid file message to pop up. Once I loaded a file successfully, closed it down and reopened it and it did fill the fields, however, when I clicked Browse for the source, it still took me to the eac3to folder rather than the last location. When I clicked Cancel on the "Select the Source File" dialog, it then removed the Source file entry. You should be able to duplicate this, I think.

It seems to do this only after you initially open the app. Once you Browse and select a source file, you can open the Browse again and hit Cancel and it will not affect the source.

I hope I've explained this well and not confused everyone. :cool: Please let me know if you need any clarification. Thanks again.

[ACrowley]

Ok, I looked it up again.

The video stream on the disc says runtime is 02:13:25:00.



The runtime of the extracted audio stream is 02:13:25:00.

The runtime of the extracted video stream at 23.976fps is 02:13:32:00.

The runtime of the remuxed MKV with timecode file at 23.976fps is 02:13:32:00.

Obviously something is wrong here, don't you think? ;)


What i know is , the untouched 23.976 HDDVD should have 133min , (2h:13m:25s):)

But strange, i know a few x264 mkv reencodes , and they all have different Runtime

I have the HDDVD here and i will tak a closer Look into it

[Thunderbolt8]

The "mathematical" correct would be the just compare the timestamps of the first audio and video packets.
I would like to try this out with future remuxes, could you please give me a little instruction how I can do that, with remuxed .mkv video and flac/.mka audio? please take into consideration that I dont really have a clue of such progs and steps I have to do :P
if I encouter a timestamp difference between video and audio, how can I calculate that back to ms of delay?
thanks!

[The_Keymaker]

@Chumbo,

The issue you encountered will only happen the FIRST TIME time you open v1.38 of EAC3toGUI. Just hit "OK" when the "unsupported filetype" dialog pops up and continue as normal. Everything will be fine after that.

Thanks for the feedback.

Regards,
The_Keymaker

[madshi]

I would like to try this out with future remuxes, could you please give me a little instruction how I can do that, with remuxed .mkv video and flac/.mka audio? please take into consideration that I dont really have a clue of such progs and steps I have to do :P
if I encouter a timestamp difference between video and audio, how can I calculate that back to ms of delay?
thanks!
Check out posts 929 und 930 of this thread.

[The_Keymaker]

New version (v1.39) uploaded which fixes the bug noted by Chumbo.

Link: http://www.sendspace.com/file/423w9l

Change log v1.39:

1 - Fixes default source file from a previous EAC3toGUI session.

Please try this new version and report any bugs.

Thanks
The_Keymaker

[Thunderbolt8]

Check out posts 929 und 930 of this thread.
the problem is that this only accounts for the rebuilt source video and audio evos, but not for the remuxed and demuxed versions in .mkv or flac/mka in the end. we (or better said you :P ) already presumed the sync problem occurs when the streams are dragged out of their native state in the container. so I guess this wont help me much. as far as I can remember all my last movies had the same identical first pts/ptm values for audio and video in evodemux (regardless of eac3, truehd or dts-hd), but some of them needed a delay, some didnt.

apart from that this would only account for HD DVD anyway, as we only have a HD DVD program that gives us such info as evodemux. what could I do in case of blu-ray? (well, xport gives info about the first video pts when demuxing video (and audio), but no info about audio, so it doenst help me much)

[Chumbo]

New version (v1.39) uploaded which fixes the bug noted by Chumbo.

Link: http://www.sendspace.com/file/423w9l

Change log v1.39:

1 - Fixes default source file from a previous EAC3toGUI session.

Please try this new version and report any bugs.

Thanks
The_Keymaker
Cool, thanks. Here are my findings:
- deleted ini file and brought it up. Came up fine w/out filling in the Source file and thus not causing the error to come up.
- clicked source browse and selected a source file then closed the app
- reopened the app with no issues
- clicked the source Browse and, woohoo, it opened the last location navigated to. I selected my source file and clicked Open with no issues.
- Immediately after I clicked my Source browse again, then I clicked Cancel which brought up the Unsupported Filetype dialog. When I clicked OK, it cleared out the Source and Destination. It also did not clear the Command Line Preview correctly as it kept the destination string even though the Destination box was cleared out.

Almost there. :)

[madshi]

the problem is that this only accounts for the rebuilt source video and audio evos, but not for the remuxed and demuxed versions in .mkv or flac/mka in the end.
Well, if you legally own the movies then there's no problem checking the timestamps with the original EVO files, right? :)

we (or better said you :P ) already presumed the sync problem occurs when the streams are dragged out of their native state in the container. so I guess this wont help me much.
Of course it will, cause the first timestamps of the different video/audio tracks are the single most important facts when thinking about audio delay. If I ever find a correct way to calculate the proper audio delay of all audio tracks then it MUST involve the pts/ptm values for the audio and video tracks. There's no other way to get it right in all situations.

as far as I can remember all my last movies had the same identical first pts/ptm values for audio and video in evodemux
I have several movies where this is not the case.

(regardless of eac3, truehd or dts-hd), but some of them needed a delay, some didnt.
Normally if the first pts/ptm values are identical, no track should need a delay. The big question is why the TrueHD tracks still do sometimes. But that doesn't mean that the pts/ptm values are in any way useless. They're extremely important. We just need to solve the mystery about why the TrueHD tracks need a delay when they really shouldn't. There must be a reason and we'll probably find it sooner or later...

apart from that this would only account for HD DVD anyway, as we only have a HD DVD program that gives us such info as evodemux. what could I do in case of blu-ray? (well, xport gives info about the first video pts when demuxing video (and audio), but no info about audio, so it doenst help me much)
So what do you want me to do? Should I write a tool which analyzes the video images with artificial intelligence to find moving mouths and then analyze the audio data to find spoken words in them which match the lip movements?

There's no way to "automatically" find the right delay value if you have no timestamp information and if the tracks are out of sync. Period. Sometimes ugly tricks like checking the length of the audio/video track might help (what you're doing), but it's not really a good solution and it will not always work.

[Thunderbolt8]

Well, if you legally own the movies then there's no problem checking the timestamps with the original EVO files, right? :)
thats not what I mean. of course I have the original evo files, what I mean is that when I compare them of course they are mostly in sync, audio and video there. but when de- and remuxing the tracks something obviously changes and then the original values only help me that much as it indicates the tracks on the original disc begin completely in sync, so when I can establish this state with the remuxed audio and video too then they should be in sync as well.
but as you already said with comparing the length it might just not be the right way each time thats why I need something like a way to compare the pts or something equal in their remuxed counterparts, like the point when the first real audio and video data occurs in those files. this should be a bit different in those cases where movies still need a delay even though, according to timestamps, it shouldnt.

im basically asking for a way to compare the final streams that will go into the mux, not the source files. maybe its possible to spot differences there with a hex editor or something like that.

[madshi]

im basically asking for a way to compare the final streams that will go into the mux, not the source files. maybe its possible to spot differences there with a hex editor or something like that.
I'm not sure why we keep on arguing about this. There's only one proper way to calculate the audio delays automatically. I see no sense in talking about any other solution.

Yes, the only proper way currently fails to work with TrueHD streams. But instead of trying to find other proper solutions (which don't exist) we should really try to find out *why* the only proper way fails to work with TrueHD streams.

[Thunderbolt8]

it was only an idea. I didnt know that having a look on the files which will go into the mux wont work so I had to ask.

btw. what was again with the DTS-HD streams? did they all generally need a delay or not? are there differences between MA and HR ?
ive already told that all the streams Ive had so far with remuxes didnt need delay, regardless of any numbers. but then again I noticed those were all studio canal titles so far and I hope theres no difference between tracks from that studio or tracks from other studios or blu-ray for example.

[madshi]

The method I explained in post 930 should work for any and all audio streams, doesn't matter which type they are.

(Obviously TrueHD makes problems, but that must have a very specific reason.)

[honai]

It's probably because TrueHD defines alignment block sizes, and when audio and video are not aligned to a specific block there is an implicit offset calculated from some schema. Unfortunately I don't have the specs.

Maybe Alex Zambelli or Ben Waggoner can help, they seem to have a lot of experience with HD disc container formats and buffer sizes from the specs.

[madshi]

It's probably because TrueHD defines alignment block sizes, and when audio and video are not aligned to a specific block there is an implicit offset calculated from some schema. Unfortunately I don't have the specs.

Maybe Alex Zambelli or Ben Waggoner can help, they seem to have a lot of experience with HD disc container formats and buffer sizes from the specs.
That does make some sense. I'll see of those two are willing to help. Thanks for the suggestion.

[The_Keymaker]

@Chumbo (and others using EAC3toGUI),

I believe this version (v1.40) should finally fix any lingering source file bugs. It certainly resolves the bug reported by Chumbo.

Link: http://www.sendspace.com/file/hzdz90

Please test and report any bugs.

I apologize for any inconvenience these bugs may cause and I appreciate everyone's patience.

Regards,
The_Keymaker

[Thunderbolt8]

The method I explained in post 930 should work for any and all audio streams, doesn't matter which type they are.

(Obviously TrueHD makes problems, but that must have a very specific reason.)
yes i know that, but then noticed that all the dts-hd titles I had so far were all from studio canal and then I suddenly was afraid it could be only due to that :P

but I recently remuxed the fly BD, which has DTS-HD MA, and it also looked fine without any delay at all there.

[Chumbo]

@Chumbo (and others using EAC3toGUI),

I believe this version (v1.40) should finally fix any lingering source file bugs. It certainly resolves the bug reported by Chumbo.

Link: http://www.sendspace.com/file/hzdz90

Please test and report any bugs.

I apologize for any inconvenience these bugs may cause and I appreciate everyone's patience.

Regards,
The_Keymaker
No need to apologize. Best way to get the bugs out is by people actually using this stuff and giving feedback. ;)

Confirmed that the last bug I reported is now fixed. So thank you.

If I may ask for a couple "wish list" items at your convenience:
- allow the Source entry to be edited. It looks like, currently, the edit box is read-only
- a queue or batch type feature where jobs can be added and then executed as a batch

Again, thanks for your hard work on this.

[The_Keymaker]

@madshi,

If you desire, please post the latest version (v1.40) of EAC3toGUI to your link on the first page.

Link to latest version: http://www.sendspace.com/file/hzdz90

Regards,
The_Keymaker

[Chumbo]

@The_Keymaker,
Small "bug" to report. Under the Conversion Options tab, "TrueHD" is misspelled in "PCM and TreuHD Options."

There also seems to be a bug in the repainting of parts of the window. For example, drag half of the app off the screen and then drag it back. You'll notice that it doesn't repaint correctly. It only seems to happen off the left side of the screen though.

http://img215.imageshack.us/img215/4126/paintissueik2.th.jpg (http://img215.imageshack.us/my.php?image=paintissueik2.jpg)

[The_Keymaker]

Will fix misspelling AND input text box-edit next release.

I can not duplicate the repainting problem on either my Vista32 system or my legacy XP system. It seems to be system specific.

Thanks for the feedback.

Regards,
The_Keymaker

[madshi]

@madshi,

If you desire, please post the latest version (v1.40) of EAC3toGUI to your link on the first page.
Done - thanks!

[hgmeier]

Hi all,

I am new in this forum and I have a question. After I have demuxed an HD-DVD with Evodemux an converted the DDPlus track to DD by using eac3to. Now I would like to put the vdeo- and audiostream back together. Which program do you recommend for that purpose?
It would be very nice if someone could make a suggestion.

Thanks,

Chris

[madshi]

I am new in this forum and I have a question. After I have demuxed an HD-DVD with Evodemux an converted the DDPlus track to DD by using eac3to. Now I would like to put the vdeo- and audiostream back together. Which program do you recommend for that purpose?
It would be very nice if someone could make a suggestion.
This is not really the right thread to discuss this as this thread is about eac3to (audio converting) only. Please search through the other threads. If you can't find a solution please post a new thread and ask there. Thanks.

[Sephiroth0000]

This forum has helped me out before so im back with more problems lol. I have a DDP audio file from EVODemux and when I run it through EAC3TO it does come up at the full time it should (that being 2hours23minutes) but yet when it converts it to WAV it is only coming out at 1hour6minutes long and yet the WAV file size is massive (6GB to be exact) I have never had this problem before and have tried numerous times now. Any suggestions anyone?