eac3to - audio conversion tool

[Thunderbolt8]

The main reason why I removed EVO input support in 1.18 was because the dialnorm removal only works with demuxed TrueHD files. So the TrueHD track you converted with 1.17 still has dialnorm applied. When creating v1.18 I noticed that I didn't clearly say that EVO input should no longer be used. And even if I documented that in 1.18 I feared that some people wouldn't read the documentation properly. So I just removed EVO input to force all people to use the proper way to have dialnorm defeated.

Sorry, my fault, should have clearly said that EVO input is not recommended, anymore (when releasing v1.17).
just to sum up the status quo: this means we can only use demuxed trueHD tracks, because otherwise that normalization removal cant work. but then we have that flac delay issue. so when seeing it right, the way to get it all right now is to wait with any conversion until you figure out how it will be right? ;)

[Sephiroth0000]

Set :

HKEY_LOCAL_MACHINE\SOFTWARE\Sonic\CommonMPEGDecoders\4.2\VideoDecoder

AllowAllRenderers to 1

Then you can use the VideoDecoder 4.3 as usual via Directshowsource in Avisynth :)

ACrowley I think I may have my AVIsynth wrong. This is what the tutorial told me to put in my Video Only.avs file

Directshowsource ("c:\HD\Video_Only.grf", fps=23.976, audio=false, seekzero=false, seek=true, framecount=196142)

I take it I am supposed to have something there in place of DIRECTSHOWSOURCE thing right? What do I put there mate or is it right? I am using Sonic 4.3

[Sephiroth0000]

Oh and also how do I set it please? Like I said im quite new to this. What do I do withh this HKEY thing? Oh and im using Sonic 4.3 not Sonic 4.2

[Thunderbolt8]

go to the command line and type 'regedit'
Oh and also how do I set it please? Like I said im quite new to this. What do I do withh this HKEY thing? Oh and im using Sonic 4.3 not Sonic 4.2
doenst matter

[madshi]

just to sum up the status quo: this means we can only use demuxed trueHD tracks, because otherwise that normalization removal cant work. but then we have that flac delay issue.
Correct.

so when seeing it right, the way to get it all right now is to wait with any conversion until you figure out how it will be right? ;)
NO.

I don't know why you're so obsessed with the "delay issue"? Having to add a small positive or negative delay to an audio track is "everyday business" for any serious reencoder. It's a very usual thing and not really an issue. The same problem sometimes (not always) also occurs with E-AC3 tracks. And you'll have the same problem everytime you try to mux a DVD audio track to a HDTV broadcast.

The only real issue right now is that delaycut doesn't support FLAC and it probably never will. However, the very next eac3to version will be able to "delay" FLAC files. You'll still have to figure the correct delay value out yourself manually, though.

Maybe sometime in the future we'll find a way to automatically determine which delay value is needed (for TrueHD, DTS-HD and also for E-AC3 tracks). But right now I don't know how to do that. But as explained above, I don't consider this as an important issue. We can handle the situation just fine today. It just needs a very little bit of additional manual work.

[madshi]

eac3to v1.19 released

http://madshi.net/eac3to.zip

* bugfix: still some TrueHD files were not accepted ("The source file format is unknown")
* added: FLAC supported as source/input file format now
* added: full delay functionality
If you want to delay a FLAC audio track by 200ms, you can now do this:

"eac3to source.flac dest.flac 200ms"

The FLAC track will then be decoded, the delay will be applied on the raw decoded audio data, and then the final raw audio data will be reencoded with FLAC again. Since FLAC is a lossless decoder this is like unzipping, changing a text file and zipping it again. There's no loss in audio quality doing it this way because FLAC is lossless. The one little disadvantages of this delay technique is that a full decode and reencode is necessary which of course costs time.

Delay also works for any other audio format, as long as decoding or encoding is involved. E.g. you can apply a delay when converting TrueHD to FLAC. However, eac3to's new delay functionality doesn't work without reencoding. If you want to delay AC3, E-AC3 or DTS files, your obvious choice is still the "delaycut" tool, of course.

[Thunderbolt8]

I don't know why you're so obsessed with the "delay issue"? Having to add a small positive or negative delay to an audio track is "everyday business" for any serious reencoder. It's a very usual thing and not really an issue. The same problem sometimes (not always) also occurs with E-AC3 tracks. And you'll have the same problem everytime you try to mux a DVD audio track to a HDTV broadcast.
its not that im obsessed with delay, I just want to be able to have it as perfectly as possible. the problem with delay is just once you know its not 100% accurate you'll notice it throughout the film and this is really anyoing. and especially with movies where mimic when speaking and quickly numbled stuff occurs throughout the whole movie in extreme ways syncing is a real nightmare, because one scene it looks fine and in the other one it doesnt any more. manually applying a delay when muxing is not a problem, but knowing a delay for such movies is almost impossible. I already synced a king kong broadcast with something like 23.9755 fps or something like that, because a static delay didnt help me,so I had to find out how to alter the video fps to come closer to the right delay and it all took hours to find out. its quite good now, but still not perfect towards the end when watching real closely.
therefore, if a way to calculate the exact delay exist, it would be an enormous help.

[madshi]

its not that im obsessed with delay, I just want to be able to have it as perfectly as possible. the problem with delay is just once you know its not 100% accurate you'll notice it throughout the film and this is really anyoing.
I see no reason why it shouldn't be possible to get it 100% accurate. Ok, maybe only 99%. But it should be possible to get the sync so near that it looks perfect to our eyes/brain.

I already synced a king kong broadcast with something like 23.9755 fps or something like that, because a static delay didnt help me,so I had to find out how to alter the video fps to come closer to the right delay and it all took hours to find out. its quite good now, but still not perfect towards the end when watching real closely.
Well, yes, trying to sync an audio track which doesn't want to fit even after a lot of work can be a royal pain in the a**. But this should happen with TrueHD/DTS-HD/E-AC3. These tracks should only need one specific static delay. And with the right delay sync should be perfect throughout the whole movie. So I do not consider this as a problem.

therefore, if a way to calculate the exact delay exist, it would be an enormous help.
It would be more comfortable. But IMO it's not that important. As I've already mentioned several times, with some movies E-AC3 tracks are not in sync, either, and need manual fixing. And nobody has even complained about that yet.

[Thunderbolt8]

well its REALLY more comfortable, when that attempt takes up several hours already. depending on how big the delay is and how much you think that video&audio is trying to fool you right now you need to remux quite often, because the mpc audio delay tool only works up to a certain limit and if thats not enough you need to remux the whole file with a delay again and try again with that mpc setting. and when doing this with disc remuxes that take up >15gb of space it begins to take a lot of time. I wouldnt say it when it only took like 15 mins altogether
I just muxed the stupid fear & loathing thing for the Xth time now, from like 50 to 500 ms and delay is almost the same, when watching (cpu usage of both cores <50%) and it seems complete oddly :(

I just added -200ms delay right now just to test and the delay hasnt really changed a bit compared to the 500ms. theres something wrong :S
added 1000ms. same delay as with 500 and -200 :/ whats wrong? could there be a problem, because I muxed the flac into .mka before muxing it all to .mkv?

[madshi]

well its REALLY more comfortable, when that attempt takes up several hours already.
It usually takes me only some minutes to figure the correct delay value out. I think you need to improve your workflow... :)

If you call MPC with the "dub" parameter, you can check delay with the external FLAC file!!! No need to do *any* muxing for delay checking.

I just muxed the stupid fear & loathing thing for the Xth time now, from like 50 to 500 ms and delay is almost the same, when watching (cpu usage of both cores <50%) and it seems complete oddly :(

I just added -200ms delay right now just to test and the delay hasnt really changed a bit compared to the 500ms. theres something wrong :S
added 1000ms. same delay as with 500 and -200 :/
Sounds strange. Does eac3to claim to apply the delay? Try adding 10000ms and check if the FLAC runtime really gets 10 seconds longer.

[Thunderbolt8]

If you call MPC with the "dub" parameter, you can check delay with the external FLAC file!!! No need to do *any* muxing for delay checking.
I know, but as I said that works only for sure for quite small delay values. can get tricky already >500 or sometimes >200 ms

[madshi]

eac3to v1.20 released

http://madshi.net/eac3to.zip

* bugfix: some Blu-Ray TrueHD tracks were not accepted
* change: eac3to output text slightly improved

[Thunderbolt8]

eac3to v1.20 released
*canceling current remuxing*

trying to do a "fresh" demuxing and conversion to flac again. maybe it helps

[madshi]

I know, but as I said that works only for sure for quite small delay values. can get tricky already >500 or sometimes >200 ms
I've no trouble with even e.g. 20 seconds of delay. With bigger delays it helps to write the delay into the "Audio Switcher" -> "Audio Time Shift" edit box and then to restart MPC. From there you can still do smaller delay changes with the keypad "+" and "-" keys. I never need more than a few minutes to find the right delay value - as long as only one static delay value is needed. Of course it takes much MUCH longer if sync keeps drifting away in the middle of the movie.

[Thunderbolt8]

hm Ive always only done it via the audio switcher -> audio time shift box and it only works for shorter delays for me. otherwise everything just get sloooooouuwww. thats why I need remuxes sometimes.
but you mean you can actually change the delay with + and - keys WHILE watching?

edit: LMAO didnt know that! omg all the hours I spent with remuxing and manually tpying etc.:S

hm regarding the external flac, I have the flac file given the same filename as the .mkv file has (apart from the .flac ending), but I cant choose it as external audio tracks. does this only work when I put the flac into .mka container?

[madshi]

hm Ive always only done it via the audio switcher -> audio time shift box and it only works for shorter delays for me. otherwise everything just get sloooooouuwww. thats why I need remuxes sometimes.
but you mean you can actually change the delay with + and - keys WHILE watching?

edit: LMAO didnt know that! omg all the hours I spent with remuxing and manually tpying etc.:S

hm regarding the external flac, I have the flac file given the same filename as the .mkv file has (apart from the .flac ending), but I cant choose it as external audio tracks. does this only work when I put the flac into .mka container?
You need to call MPC with the "dub" command line parameter. Otherwise MPC doesn't pick the "flac" file extension up as an external audio track. Using that "dub" parameter you can even feed MPC TrueHD and DTS-HD EVO and M2TS files as external audio tracks!

[ACrowley]

I'm not sure. I think 1.18 should just complain about the dirty track, but try to continue. Maybe the audio decoder stopped? How does the full text output look like?

Anyway, you can avoid to have a corrupted audio file in the first place. EvoDemux has a bug with Perfume. I fear if you have rebuilt the DTS-HD tracks into a separate EVO file you might already have corrupted the audio files. Try demuxing the original EVO file by using drmpeg's EVO demuxer. Here's the download link:

http://www.w6rz.net/evob_demux.zip

Using that instead of EvoDemux for Perfume results in perfectly clean DTS-HD tracks. Unfortunately Perfume only has DTS-HD High Resolution tracks encoded from a 16bit master. So the Sonic audio decoder forcefully downconverts to 16bit. I'm not sure which is better: DTS-HD High Resolution downconverted to 16bit (Sonic) or just the core, but with full 24bit (Nero).


Ok....Problem is i dont have the evos anymore from Perfume
Both DTSHD was demuxed via SonicHDDemuxer in graphedit.

eac3to Text is simple :
DTS Hi-Res, 5.1 channels, 2:28:00, 16 bits, 2082kbit/s, 48khz, dialnorm: -4dB
g:\

It stops without processing...all other dtshd tracks are working perfect

DTS HD 6.1 Discrete isnt supported at the Moment right ? On Xmen3 BluRay DTSHD 6.1 is get a unsupported Message from eac3to

Ah, and the dtscore from Perfum is 16 bit , not 24bit....

[Zelos]

Hi all,

i have something strange.
i tried to encode dtshd source ( riddick ) and get this message.


J:\Test Riddick\eac3to119>eac3to feature.dtshd test.dts -768
DTS, 5.1 channels, 2:14:31, 24 bits, 1536kbit/s, 48khz
This is already a normal DTS file.

[madshi]

Ok....Problem is i dont have the evos anymore from Perfume
Both DTSHD was demuxed via SonicHDDemuxer in graphedit.

eac3to Text is simple :
DTS Hi-Res, 5.1 channels, 2:28:00, 16 bits, 2082kbit/s, 48khz, dialnorm: -4dB
g:\

It stops without processing...all other dtshd tracks are working perfect
v1.21 will at least try to decode. Well, it does on my PC at least. However, the Sonic Audio Decoder crashes due to the corrupt file. So it doesn't really help. Most DTS tracks have no CRC, so the decoder can't check if a frame is valid or not.

DTS HD 6.1 Discrete isnt supported at the Moment right ? On Xmen3 BluRay DTSHD 6.1 is get a unsupported Message from eac3to
Try v1.21.

[madshi]

i have something strange.
i tried to encode dtshd source ( riddick ) and get this message.

J:\Test Riddick\eac3to119>eac3to feature.dtshd test.dts -768
DTS, 5.1 channels, 2:14:31, 24 bits, 1536kbit/s, 48khz
This is already a normal DTS file.
That's not really all that strange. Some DTS tracks taken from HD DVD and Blu-Ray are simple conventional DTS tracks and not DTS-HD tracks. So there's nothing you need to do. The track you have is already a normal DTS track. No conversion necessary for this one.

[Zelos]

ok thanks madshi i understand now.
but how to encode to 768k ?

[madshi]

This must be something like the twentiest release in the last few days. I will slow down soon, though. Just doing the necessary bugfixes and then I'll take a little break.

eac3to v1.21 released

http://madshi.net/eac3to.zip

* bugfix: 2 channel DTS files were not accepted
* added: DTS-ES 6.1 support
* added: DTS-HD High Resolution Matrix 5.1 support
* added: DTS-HD Master Audio 6.1 support
The discrete 6.1 DTS formats only have one additional channel, opposed to LPCM tracks who have two channels (which are identical, though). To keep everything more or less similar, eac3to is doubling the 6th channel, so that 6.1 DTS tracks end up being 7.1. Of course you can use the "-down6" parameter to limit output to 5.1.

If you find any further DTS or DTS-HD tracks which eac3to is still not accepting, please send me a small sample.

[madshi]

ok thanks madshi i understand now.
but how to encode to 768k ?
Oh, I see! Currently eac3to doesn't understand what you want. You want to reencode DTS to DTS. eac3to didn't expect that because it always things that you want the max audio quality. However, you can work around that by doing "eac3to source.dts dst.wavs". This will give you 6 mono channels. You can then manually feed them to Surcode for encoding with 768kbps. It's a bit more work to do it this way, but the end result should be fine. You should run the final DTS track through delaycut, though, to remove the zero byte padding Surcode usually applies to DTS encodes.

[Zelos]

Perfect madshi !
thanks for the help.

[Thunderbolt8]

You need to call MPC with the "dub" command line parameter. Otherwise MPC doesn't pick the "flac" file extension up as an external audio track. Using that "dub" parameter you can even feed MPC TrueHD and DTS-HD EVO and M2TS files as external audio tracks!
hm have a lot of trouble with that. tried it now with additional commands "pathname:\filename.mkv /dub pathname:\filename.flac"
but coreflac kept crashing all the time right at the start of mpc. I set it to block, it still kept crashing. I removed it as external filter and set ffdshow audio decoder to active instead, but coreflacdecoder still was active and kept crashing. only when I unregistred the coreflacdecoder.ax file via regdrop it would accept ffdshow as audio renderer. but then it made those funny clicking noises all the time, no normal sound came at all and eventually also crashed.
guess I have to stick to the remuxed .mka file when I want to find out the delay :S

[nautilus7]

Hi, i tried to convert a 5.1 dts track to mono wavs using tranzcode and eac3to, but each program gave me different size files:

1. eac3to wav (center channel) 1.116.851.756 bytes
2. tranzcode wav (center channel) 1.489.135.660 bytes

Eac3to reports no DiagNorm in the dts and i used the disable DRC option in tranzcode (don't really know if there's any DRC though). Both wavs look identical in Audacity.

[tebasuna51]

Hi, i tried to convert a 5.1 dts track to mono wavs using tranzcode and eac3to, but each program gave me different size files:

1. eac3to wav (center channel) 1.116.851.756 bytes
2. tranzcode wav (center channel) 1.489.135.660 bytes

Eac3to reports no DiagNorm in the dts and i used the disable DRC option in tranzcode (don't really know if there's any DRC though). Both wavs look identical in Audacity.

The default output for Tranzcode is 32 bits float per sample, but eac3to seems output 24 bit int. This is the difference in size.

With Tranzcode you can use the parameter /24 to obtain a equivalent output.

[madshi]

hm have a lot of trouble with that. tried it now with additional commands "pathname:\filename.mkv /dub pathname:\filename.flac"
but coreflac kept crashing all the time right at the start of mpc. I set it to block, it still kept crashing. I removed it as external filter and set ffdshow audio decoder to active instead, but coreflacdecoder still was active and kept crashing. only when I unregistred the coreflacdecoder.ax file via regdrop it would accept ffdshow as audio renderer. but then it made those funny clicking noises all the time, no normal sound came at all and eventually also crashed.
guess I have to stick to the remuxed .mka file when I want to find out the delay :S
The CoreFlac filter never worked well for me. Try this one:

http://www.free-codecs.com/download/DC-Bass_Source_Filter.htm

It works very well. However, it has two problems:

(1) Output is always only 16bit.
(2) Seeking only works in the first 2GB of the FLAC file.

It's still good enough to do syncing, though. When you're done with syncing, you can still mux the final FLAC file into some container to work around the 2 bugs of this filter.

[nautilus7]

The default output for Tranzcode is 32 bits float per sample, but eac3to seems output 24 bit int. This is the difference in size.

With Tranzcode you can use the parameter /24 to obtain a equivalent output.
:thanks:

[Thunderbolt8]

The CoreFlac filter never worked well for me. Try this one:

http://www.free-codecs.com/download/DC-Bass_Source_Filter.htm

It works very well. However, it has two problems:

(1) Output is always only 16bit.
(2) Seeking only works in the first 2GB of the FLAC file.

It's still good enough to do syncing, though. When you're done with syncing, you can still mux the final FLAC file into some container to work around the 2 bugs of this filter.
hm I need some of the last sections for fear & loathing for syncing, so it wont work for me at least for this movie. But I could just mux it into .mka additionally and then sync it from there and then apply the delay to the .flac file and delete the .mka. flac muxed in mka has still exactly the same delay as before, has it? or could there be some differences because of that putting into the container?

[madshi]

hm I need some of the last sections for fear & loathing for syncing, so it wont work for me at least for this movie. But I could just mux it into .mka additionally and then sync it from there and then apply the delay to the .flac file and delete the .mka. flac muxed in mka has still exactly the same delay as before, has it? or could there be some differences because of that putting into the container?
Yeah, that should work. I think the delay should be the same inside mka as it is outside. Well, if not, you'll find out soon enough... :)

[ACrowley]

This must be something like the twentiest release in the last few days. I will slow down soon, though. Just doing the necessary bugfixes and then I'll take a little break.

eac3to v1.21 released

http://madshi.net/eac3to.zip

* bugfix: 2 channel DTS files were not accepted
* added: DTS-ES 6.1 support
* added: DTS-HD High Resolution Matrix 5.1 support
* added: DTS-HD Master Audio 6.1 support
The discrete 6.1 DTS formats only have one additional channel, opposed to LPCM tracks who have two channels (which are identical, though). To keep everything more or less similar, eac3to is doubling the 6th channel, so that 6.1 DTS tracks end up being 7.1. Of course you can use the "-down6" parameter to limit output to 5.1.

If you find any further DTS or DTS-HD tracks which eac3to is still not accepting, please send me a small sample.

WOW ! Perfect

Until eac3to there was no To0l which decodes 6.1 dts to 7 mono waves :)

Madhsi ,i think Sonic Decoder is Refertnce Decoder ,right ?
So ,for the max Quality its perfect for all DTS decodes i think so ?
I mean it should be similar or better in Quality compared with Tranzcode or NicDTSSource or Foobar ?

Mh..i will take it for all my dts in the future :)

@zelos
Riddick HDDVD has a standard dts File...you can take without any change

@nautilus
Tranzcode use no DRC on dts decoding by default.
But for AC3 tranzcode applies DRC ,but no DialNorm.

[madshi]

i think Sonic Decoder is Refertnce Decoder ,right ?
Yes, I think so.

So ,for the max Quality its perfect for all DTS decodes i think so ?
As far as I can say: Yes.

I mean it should be similar or better in Quality compared with Tranzcode or NicDTSSource or Foobar ?
Yep. FWIW, I've compared DTS decoding with Nero, Sonic and Ac3Filter. Nero and Sonic decodes were identical to the last bit! Probably both are using the DTS reference code. Ac3Filter was too loud. I reencoded the Ac3Filter with Surcode and decoded it again with Ac3Filter. The peaks got bigger and bigger! So definitely too loud. With Sonic the volume stayed the same even with an additional Sonic -> Surcode -> Sonic step.

One thing to note: For DTS Discrete 6.1 decoding you may need to manually set OS settings to 7.1 speakers. Otherwise Sonic might only output 5.1. I'll work around that with the next eac3to build. The OS settings will then not matter, anymore.

[Thunderbolt8]

have a bit of a problem with an eac3 -> flac commentary track in media player classic. the track is DD+ 2.0 192kbps 24-bit and plays fine in an outside .mka file along the movie .mkv but when muxing it into the .mkv file and selecting it via filters -> pathnamefilename -> commentary track, the playback of both, video and audio is suddenly accelerated, the video is running with ~40fps and sound has mickey mouse voices (muxed video with timecodes to 23.9760239). again everything is fine with the normal 5.1 eac3 -> flac track (wasnt even delay needed), but as soon as I switch to the commentary track inside the .mkv this happens. tried both, coreflac and also ffdshow audio decoder, but same result.

[madshi]

have a bit of a problem with an eac3 -> flac commentary track in media player classic. the track is DD+ 2.0 192kbps 24-bit and plays fine in an outside .mka file along the movie .mkv but when muxing it into the .mkv file and selecting it via filters -> pathnamefilename -> commentary track, the playback of both, video and audio is suddenly accelerated, the video is running with ~40fps and sound has mickey mouse voices (muxed video with timecodes to 23.9760239). again everything is fine with the normal 5.1 eac3 -> flac track (wasnt even delay needed), but as soon as I switch to the commentary track inside the .mkv this happens. tried both, coreflac and also ffdshow audio decoder, but same result.
That's weird. I mean if it works inside the .mka file why doesn't it work in the .mkv file? mka and mkv are really the same. Can't explain it... :(

[Thunderbolt8]

found a little workaround for my truehd syncing problem with fear & loathing. I also demuxed the english 5.1dd+ stream and compared the length of both tracks. I guess the difference is the delay I need then for my trueHD track. at least I guess its now the same as to be observed with the original evo. still, even that seems to bit off sometimes there are lot of scenes in that movie where the delay could be +100ms more as well. if it wasnt for that eac3 track I would have had to guess forever.

[nautilus7]

@ madshi

May i suggest to add .ac3 decoding to .wav(s)? I think this would be good as eac3to can all other conversions, except this one. Then, eac3to will become the most complete audio tool.

[ACrowley]

@ madshi

May i suggest to add .ac3 decoding to .wav(s)? I think this would be good as eac3to can all other conversions, except this one. Then, eac3to will become the most complete audio tool.

yeah, but imho there are enough 100% perfect working Methods/Tools

Behappy-NicAsC3Source / Azid etc..

@Madhsi
Yep. i noticed too that AC3Filter DTS decodes are to loud! Peaks are louder compared with any other decoder.
This is not DialNorm related ..its simply to loud

[madshi]

found a little workaround for my truehd syncing problem with fear & loathing. I also demuxed the english 5.1dd+ stream and compared the length of both tracks. I guess the difference is the delay I need then for my trueHD track. at least I guess its now the same as to be observed with the original evo. still, even that seems to bit off sometimes there are lot of scenes in that movie where the delay could be +100ms more as well. if it wasnt for that eac3 track I would have had to guess forever.
With "length" you mean the runtime, I guess? I'm not sure if that is a reliable way to find out delay. Especially if the E-AC3 track is not in sync, either (which happens on some HD DVDs). But it might be a good starting point, so that afterwords only fine tuning is needed?

[nautilus7]

yeah, but imho there are enough 100% perfect working Methods/Tools

Behappy-NicAsC3Source / Azid etc..
Yes, but it would be perfect if there is an all-in-one tool. I 'm not complaining though, eac3to is very good.

[madshi]

May i suggest to add .ac3 decoding to .wav(s)? I think this would be good as eac3to can all other conversions, except this one. Then, eac3to will become the most complete audio tool.
The main problem with that is that all reference AC3 decoders are usually applying DRC when being used outside of their native player software. So if I added AC3 decoding support through Sonic's or Nero's AC3 decoder, we'd end up with DRC. Of course I could use AC3Filter or a similar open source decoder. That way I could probably get around DRC, but then that wouldn't be the reference decoder and there are lots of other tools which do it that way.

[Thunderbolt8]

With "length" you mean the runtime, I guess? I'm not sure if that is a reliable way to find out delay. Especially if the E-AC3 track is not in sync, either (which happens on some HD DVDs). But it might be a good starting point, so that afterwords only fine tuning is needed?
at least the ac3 track seemed to be in sync, cant say if he is 100%, its just too difficult for that movie.
another question, when just opening one of the 2 single .evo files and checking the sound from there, could it also be possible that theres a little delay then, so that its basically only 100% accurate when starting the complete movie 'normally'. or are the delays, when just opening the evo files seperately, also always accurate?

[madshi]

at least the ac3 track seemed to be in sync, cant say if he is 100%, its just too difficult for that movie.
another question, when just opening one of the 2 single .evo files and checking the sound from there, could it also be possible that theres a little delay then, so that its basically only 100% accurate when starting the complete movie 'normally'. or are the delays, when just opening the evo files seperately, also always accurate?
I'm not sure about that. I'm always first joining the movie and muxing it to MKV before I sync the audio tracks.

[TheSof]

Using the latest eac3to, to go from supermanreturns.thd to flac, it gave an flac with a different runtime:

thd 2:34
flac 2:47

Same with V for Vendetta, an extra 10mins.

With v1.17 (i think thats the version, the one where it didn't to 16bit, had dial norm) the runtimes were the same. I can't test it at the moment, but why would this be?

[Thunderbolt8]

I'm not sure about that. I'm always first joining the movie and muxing it to MKV before I sync the audio tracks.
I just asked because I always used that single original .evo file as syncing reference. but in case this could out of sync too, I would always try to sync my remuxes wrong then -.-

[honai]

@madshi

Well, if you added "native" AC3 decoding I might be tempted to create a GUI that incorporates all the latest features of your tool.

[madshi]

Using the latest eac3to, to go from supermanreturns.thd to flac, it gave an flac with a different runtime:

thd 2:34
flac 2:47

Same with V for Vendetta, an extra 10mins.

With v1.17 (i think thats the version, the one where it didn't to 16bit, had dial norm) the runtimes were the same. I can't test it at the moment, but why would this be?
Can't imagine that there'd be a difference between v1.17 and v1.18. Except if you fed the EVO file into v1.17 instead of the demuxed file? Please check if the 2:47 FLAC stays in sync throughout the movie (after you applied the eventually necessary static delay). Maybe the 2:47 has some extra seconds of silence at the end or beginning of the movie? Don't know...

[madshi]

I just asked because I always used that single original .evo file as syncing reference. but in case this could out of sync too, I would always try to sync my remuxes wrong then -.-
The first EVO part should be in sync. But I'm not sure about the 2nd part.

[madshi]

Well, if you added "native" AC3 decoding I might be tempted to create a GUI that incorporates all the latest features of your tool.
Are there important features missing in The_Keymaker's GUI? I've no idea, I'm always using the command line, only...

Maybe I'll add AC3 decoding if I find a way to disable DRC in a reference decoder. That would be worthwhile. But it will be a while before I invest time into that. I've spent too much time on eac3to lately.

[honai]

Are there important features missing in The_Keymaker's GUI? I've no idea, I'm always using the command line, only...

His latest version is missing some command-line parameters.

Maybe I'll add AC3 decoding if I find a way to disable DRC in a reference decoder.

Yes, that's the idea.

By the way, do you have plans to implement STDIN streaming for the source?