eac3to - audio conversion tool

[nautilus7]

Well, first of all... Does the order i specify the options has anything to do? No, right? (i use eac3to long enough so... it can't be that )

I 've done it several times and never got that big difference, but i think this is the first time i have to apply such a huge delay. I guess that's why i notice this behavior now.

I want the delay to be applied to the slowdown track. In my mind i do the actions in this order: 1.slowdown 2.delay 3.encode.

[nautilus7]

Originally Posted by madshi

A sample would be great. I think the dialog normalization removal doesn't work for this specific track (don't know why). The libav decoder never applies dialog normalization, so it works fine nevertheless. But the Nero decoder does apply dialog normalization if it's in the TrueHD stream.

Here's the sample you asked for.

[madshi]

Originally Posted by nautilus7

Well, first of all... Does the order i specify the options has anything to do?

No.

Originally Posted by nautilus7

I want the delay to be applied to the slowdown track. In my mind i do the actions in this order: 1.slowdown 2.delay 3.encode.

Yeah. But how can eac3to know? Maybe someone else thinks about: 1. delay 2. slowdown 3.encode? E.g. I'm thinking about the h264 HDTV broadcasts I'm recording here in Germany. If I want to convert them to 24p, I'd first add a PAL DVD track to the original 50i recording. For that to work I'd first need to find out the necessary delay. Afterwards I then need to slowdown the PAL DVD track and rewrite the video timestamps. Doing it this way I'd need to do 1. delay 2. slowdown 3. encode.

So as far as I can see when you do slowdown and delay at the same time eac3to simply doesn't know in which order to do things. Both order variations can be right or wrong depending on what the user wants. The only way to solve this properly would be to let eac3to make use of the order in which you specified the delay and slowdown options. But then there are further problems: If you demux an audio track from an EVO file and at the same time want to apply PAL speedup and delay it, there'd be the automatic delay correction which HAS to be made before speedup, then the speedup and finally the manual delay. That's all getting extremely confusing. So my recommendation is that in such situations you should probably better do the operations in 2 steps, so that there's no room for interpretation.

[madshi]

Originally Posted by nautilus7

Here's the sample you asked for.

Thanks. Just tested it. The sample size is 11.1MB. Transcoding to FLAC with libav results in 9.68MB. Transcoding to FLAC with Nero also results in 9.68MB for me. Compared the two FLAC files and they are bit identical.

Can your buddy please retest whether he can reproduce the problem with the 10MB sample? Also please let him check whether he's using the latest eac3to version. And let him run "eac3to -test".

[nautilus7]

Originally Posted by madshi

No.


Yeah. But how can eac3to know? Maybe someone else thinks about: 1. delay 2. slowdown 3.encode? E.g. I'm thinking about the h264 HDTV broadcasts I'm recording here in Germany. If I want to convert them to 24p, I'd first add a PAL DVD track to the original 50i recording. For that to work I'd first need to find out the necessary delay. Afterwards I then need to slowdown the PAL DVD track and rewrite the video timestamps. Doing it this way I'd need to do 1. delay 2. slowdown 3. encode.

So as far as I can see when you do slowdown and delay at the same time eac3to simply doesn't know in which order to do things. Both order variations can be right or wrong depending on what the user wants. The only way to solve this properly would be to let eac3to make use of the order in which you specified the delay and slowdown options. But then there are further problems: If you demux an audio track from an EVO file and at the same time want to apply PAL speedup and delay it, there'd be the automatic delay correction which HAS to be made before speedup, then the speedup and finally the manual delay. That's all getting extremely confusing. So my recommendation is that in such situations you should probably better do the operations in 2 steps, so that there's no room for interpretation.

Ok, i see.

Maybe you can modify eac3to to "care" about the order of these 2 switches (slowdown, delay) when they are applied together. But i really don't mind. If you can make without investing much time and you want to, do it. I am happy there isn't a bug in eac3to.

[nautilus7]

Originally Posted by madshi

Thanks. Just tested it. The sample size is 11.1MB. Transcoding to FLAC with libav results in 9.68MB. Transcoding to FLAC with Nero also results in 9.68MB for me. Compared the two FLAC files and they are bit identical.

Can your buddy please retest whether he can reproduce the problem with the 10MB sample? Also please let him check whether he's using the latest eac3to version. And let him run "eac3to -test".

I'll tell him to check again. Thanks for your time.

[Wackyphill]

Originally Posted by Beastie Boy

My copy of 300 has the same file names as yours, the TrueHD track does not have a delay. I had no synch problems when the files were remuxed.

Cheers, Beastie.

Thanks for the info! It seems to be a problem w/ my process. I tried w/ Harry Poter 2 also and got the same sync problem. I've been using AnyDVD to rip the disc before using eac3to on the evo files. Does anyone know if AnyDVD can cause this sync problem?

If not it seems maybe to be a decoder problem? The video is VC1, the audio encoded into flac from the dolby true HD. What are the reccomended codecs for playback of this type?

I've just been installing ffdshow. Thanks for any help.

[Beastie Boy]

Originally Posted by nautilus7

Maybe you can modify eac3to to "care" about the order of these 2 switches (slowdown, delay) when they are applied together.

Perhaps I'm being a bit slow here, but I can't think of any occasion when you would want to apply the speed change before applying the delay
When the video and audio are extracted with the delay automatically applied, you now have an audio file and a video file that are the same duration and in synch. If the same speed change is now applied to both, they will remain in synch. Therefore, even if the audio is done as a 1 step process, the delay should always be applied first.
Or am I missing something?

Cheers, Beastie.

[Beastie Boy]

Originally Posted by Wackyphill

Thanks for the info! It seems to be a problem w/ my process.

Without knowing your process, it's hard to comment. Re-encoding vc1 video with the Sonic video filters in the Graphedit chain can cause synch to drift.
I do know that it is not a eac3to problem, so perhaps it would be better to discuss your problem in another thread.

Cheers, Beastie.

[madshi]

Originally Posted by Wackyphill

Thanks for the info! It seems to be a problem w/ my process. I tried w/ Harry Poter 2 also and got the same sync problem. I've been using AnyDVD to rip the disc before using eac3to on the evo files. Does anyone know if AnyDVD can cause this sync problem?

If not it seems maybe to be a decoder problem? The video is VC1, the audio encoded into flac from the dolby true HD. What are the reccomended codecs for playback of this type?

I've just been installing ffdshow. Thanks for any help.

You should really try to find out which filters are being used on your PC. I take it you have remuxed the video to MKV, right? Have you muxed the FLAC track into the MKV, too? Or are you playing the FLAC track externally? Personally, I'm using madFlac for FLAC decoding.

[nautilus7]

Originally Posted by Wackyphill

Does anyone know if AnyDVD can cause this sync problem?

AnyDVD doesn't cause any problems, unless you use the explorer to rip the disc. Then you may end up with corrupted files.

[madshi]

Originally Posted by Beastie Boy

Without knowing your process, it's hard to comment. Re-encoding vc1 video with the Sonic video filters in the Graphedit chain can cause synch to drift.
I do know that it is not a eac3to problem, so perhaps it would be better to discuss your problem in another thread.

Agreed. If the problem is not related to eac3to at all, it would make sense to discuss elsewhere. This thread is long enough as it is already...

[nautilus7]

Originally Posted by Beastie Boy

Perhaps I'm being a bit slow here, but I can't think of any occasion when you would want to apply the speed change before applying the delay
When the video and audio are extracted with the delay automatically applied, you now have an audio file and a video file that are the same duration and in synch. If the same speed change is now applied to both, they will remain in synch. Therefore, even if the audio is done as a 1 step process, the delay should always be applied first.
Or am I missing something?

Cheers, Beastie.

Yes you are right.

First, i apply -slowdown and decode the pal track to wav.
Then, i decode to wav the original ntsc track of the movie.
After, i figure out the delay by checking multiple points of the decoded wavs (using an audio editor). I only make dub tracks for animation which is difficult to find the exact delay.
Finally, i encode the final ac3 audio by applying slowdown and delay at one step.

Confused?

[Beastie Boy]

Originally Posted by nautilus7

Confused?

Yes

[madshi]

Originally Posted by nautilus7

First, i apply -slowdown and decode the pal track to wav.
Then, i decode to wav the original ntsc track of the movie.
After, i figure out the delay by checking multiple points of the decoded wavs (using an audio editor). I only make dub tracks for animation which is difficult to find the exact delay.
Finally, i encode the final ac3 audio by applying slowdown and delay at one step.

Slowing down is what consumes the most time. So why don't you reuse the slowed down WAV file from your first step to encode the final AC3 file? You'd only have to slowdown once that way and would save time.

[nautilus7]

The wav file is actually mono wavs (-mono switch, remember?).
But a 2 hour movie won't fit in 6 channel wave because of the 4 GB limit.

I 'll have to re-consider my method, anyway...

[nautilus7]

Originally Posted by Beastie Boy

Yes

I know... even i would be!

Assume you have a 23,976 fps track and a pal (25 fps) dub track of an animation movie. And because you have a brain damage (that's me ) you want to have perfect sync even if you never hear a difference. How would you do it?

I take the original (23,976) track and decode it to wav(s) (center channel is enough) and open it in a wav editor. Then i do the same for the 25 fps dub with slowdown applied.
This way i can compare=find the delay. Actually i check multiple point of the tracks to be sure (the brain damage we were talking ) so i need them to be in the same fps (slowdown must be done already).

Hope you understand. Sorry for spoiling the topic.

[nautilus7]

Originally Posted by madshi

Thanks. Just tested it. The sample size is 11.1MB. Transcoding to FLAC with libav results in 9.68MB. Transcoding to FLAC with Nero also results in 9.68MB for me. Compared the two FLAC files and they are bit identical.

Can your buddy please retest whether he can reproduce the problem with the 10MB sample? Also please let him check whether he's using the latest eac3to version. And let him run "eac3to -test".

He can reproduce the problem with the sample (he gets ~30MB). Uses latest eac3to, -test switch shows nero working ok. He has Vista 64bit.

I also tried the sample. Size ok here. I told him to re-install nero (he has v7.10.1.0 installed)

[nesNYC]

Okay madshi, first I'd like to thank and congratulate you on such a nice tool. So far I've re-encoded about 4 DD+ movies without any issues. DD+ seems to work fine.

Now my only issue is on THE_CHRONICLES_OF_RIDDICK, the track I want to use is DTSHD. When I play the audio track back, it's 2:11:42 in lenght, this coming right off of a EVODemux, demux. The movie, however, is 2:14:04 in length.

I've tried to apply 57ms delay (with eac3to) and try to get the DTS track to be 2:14:04 in length as well but it seems no matter what number I use in delay, when I play the track back it's still it's default time. Does adding delay in eac3to simply put markers for sync or does it actually try and time stretch the files to fit? I've read a lot of pages on this thread but cannot figure this one out. Should be simple right?

What's annoying is that the DTSHD file sounds so much better than the DD+ file and upto 1/3 into the movie, things are pretty much in sync. But by the end there is an amost 2 to 3 second delay, aaarrrhhh, LOL!

Any suggestions?

BTW, I also used the TrueHD -> DTS conversion suing SurCode and it also worked like a charm. I am having no delay issues on anything other than DTS(HD).

[hristoff2]

Try demuxing DTS core (blabla.dtshd blabla.dts -core) and mux the DTS stream with your video. Some DTS tracks have odd runtimes but muxed in matroska they're alright.