eac3to - audio conversion tool

[madshi]

Originally Posted by Rectal Prolapse

Can the removal of pulldown be made an option? This might cause big problems when demuxing an HD-DVD VC1 track for use with Blu-ray authoring! Removing pulldown could cause playback to fail on standalone blu-ray players.

Is that so? Never heard about that yet. Are you sure?

Currently pulldown removal is default. But you can disable it by using the (undocumented) option "-keepPulldown". If removing the pulldown is really problematic for Blu-Ray authoring, I'll revert the default to not doing pulldown and will offer an option for removing pulldown instead.

[madshi]

Originally Posted by Thunderbolt8

can someone just please exlain me what that pulldown thing again was? it was something with the framerate, I suppose. so when I the framerate altered now (and to what?), only when the VC-1 tracks are demuxed, but for remuxing they are kept in their original state?

HD DVD video streams are 1080p24, but they come with additional "pulldown" flags which tell the player how to best output the stream when doing 1080i60. These pulldown flags are missing in Blu-Ray streams. It seems that for Xbox remuxing the pulldown flags need to be removed.

[madshi]

Originally Posted by rickardk

What does this mean?

E:\EAC3TO>eac3to feature_1.evo+feature_2.evo 2: born.mkv 3: born.flac
EVO, 1 video track, 3 audio tracks, 2:24:16
1: Joined EVO file
2: VC-1, 1080p24 /1.001
3: E-AC3, 5.1 channels, 1536kbit/s, 48khz, dialnorm: -27dB
4: E-AC3, 2.0 channels, 448kbit/s, 48khz, dialnorm: -27dB
5: E-AC3, 2.0 channels, 192kbit/s, 48khz, dialnorm: -27dB
Extracting secondary video track...
Muxing video to Matroska...
Extracting audio track number 3...
Removing dialog normalization...
Decoding with DirectShow (Nero Audio Decoder 2)...
Disabling DRC for Nero (E-)AC3 decoding...
DirectShow reports 5.1 channels, 24 bits, 48khz
Encoding FLAC...
Creating/writing file "born.flac"...
Video has a gap of 3 frames at playtime 0:00:53.
Video overlaps for 3 frames at playtime 0:00:59.
Video has a gap of 2 frames at playtime 0:01:20.
Video overlaps for 2 frames at playtime 0:01:23.
Video has a gap of 3 frames at playtime 0:01:53.
Video overlaps for 3 frames at playtime 0:01:56.
Video has a gap of 3 frames at playtime 0:02:40.
Video overlaps for 3 frames at playtime 0:03:09.

First of all: Please trash this MKV. It's no good. Please retry with v2.16. If the same problem is still there, a sample which covers the first 0:03:15 runtime of the movie would be very helpful.

This one is complicated. Let me try to explain:

-----------------------

Normally an EVO movie contains a video track which is encoded in 1080p24. There are normally exactly 24/1.001 frames per second in the video track. Furthermore the EVO container contains some timecodes for some video frames (but not for all). E.g. the container might say: "frame 305 has the timecode 0:01:50". Now there are different ways to remux such an EVO to MKV:

(1) You could totally ignore the timestamps of the EVO container and just mux the movie as a constant stream of 1080p24 frames. Basically this is what mkvtoolnix does when you rewrite timecodes. It's a good approach cause you get very smooth playback with usually no micro stuttering issues. HOWEVER, there's no guarantee that you'll get perfect audio/video sync this way cause it's theoretically possible that there are gaps or overlaps in the EVO file. I mean it's possible that the EVO codes frame 10 to have timecode 0:01:50 and frame 11 to have timecode 0:01:55. So there would be 5 seconds worth of video frames missing in this case. Such cases do exist in real life. E.g. the Equilibrium HD DVD is such a beast. Now if you ignore the EVO timestamps and simply remux this to MKV the stupid way, the MKV will play 5 seconds shorter than the EVO would play.

(2) The 2nd approach would be to strictly follow the timestamps of the EVO file. The problem with this is that only some video frames have timestamps but not all. So you need to guess the timestamps for the frames which don't have timecodes. This is what Haali's Media Splitter does. This is a bumpy ride, though, cause if you guess bad, it might happen that the timecodes are not fluid, which results in micro stuttering. E.g. when using the Haali Media Splitter -> Haali Matroska Muxer, it sometimes happens that frame e.g. 55 gets a timestamp in the final MKV file which is *later* than frame 56. Obviously this results in noticably stutter.

(3) Now eac3to tries to find a good balance between (1) and (2). eac3to starts with the approach that the stream probably has no gaps or overlaps. So it applies very exact 24/1.001 timecodes to every frame. But at the same time eac3to also checks the EVO timestamps. If the EVO timestamps differ too much from where eac3to is going, eac3to notices that, outputs a warning message and corrects its timecode calculation accordingly.

In your case eac3to has detected alternating gaps and overlaps of 2-3 frames. This shows how instable the EVO timecodes sometimes are. But it also shows that with your EVO file the EVO timestamps in the long run agree with eac3to's calculation because the overlaps and gaps even out over time. I've now modified eacto v2.16 a bit so that it is a bit more relaxed in trying to find gaps/overlaps. Hopefully that will fix the problem with this movie. If not, please let me know.

-----------------------

Ouch, long explanation. Hopefully it was understandable!

[madshi]

eac3to v2.16 released

http://madshi.net/eac3to.zip

* fixed "eac3to -test" crash
* fixed "eac3to some.ddp some.wav" crash
* made video gap/overlap detection a little more relaxed
* WAV header is initialized to 4GB instead of 0GB (for stdout)
* fixed incorrect "primary/secondary" text

[shanghai2004]

Originally Posted by madshi

eac3to v2.16 released

http://madshi.net/eac3to.zip

* fixed "eac3to -test" crash
* fixed "eac3to some.ddp some.wav" crash
* made video gap/overlap detection a little more relaxed
* WAV header is initialized to 4GB instead of 0GB (for stdout)
* fixed incorrect "primary/secondary" text

Great tool is getting better!

Good news is that eac3to can now directly process VC1 files. Bad news: now I can reconfirm the MKV muxing part of the process really doesn't like VC1 interlaced files. When I demux the EVO with eac3to into videostream.vc1 and do

eac3to videostream.vc1 test.mkv

I see basically the same problem as before (See my post 1080482): the muxing runs for a while and then hangs.

I'm aware this problem is most probably not cased by the eac3to code, but somewhere in the muxer. Maybe you ever going to write a muxer as well

In the mean time, what is a good way for me to produce a test case to feedback to the Haali developers?

[madshi]

Originally Posted by shanghai2004

I'm aware this problem is most probably not cased by the eac3to code, but somewhere in the muxer.

I think so, too.

Originally Posted by shanghai2004

In the mean time, what is a good way for me to produce a test case to feedback to the Haali developers?

Just try to create a sample, which is as small as possible, upload it somewhere and post a link to the sample with a problem description to the Haali thread.

Originally Posted by shanghai2004

When I demux the EVO with eac3to into videostream.vc1 and do

eac3to videostream.vc1 test.mkv

I see basically the same problem as before

Just for your information: With v2.16 demuxing the VC-1 stream and then muxing it to MKV is not much different than asking eac3to to remux the VC-1 stream directly from EVO to MKV. The only difference is that when demuxing the VC-1 stream first, eac3to loses the chance to check for video gaps/overlaps.

[rickardk]

Originally Posted by madshi

Another proof for what I always said, namely that using the Haali Muxer is the better approach for video remuxing. Anyway, the mkvmerge problem is fixed in the latest mkvmerge beta build.

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/

The attachments in doom9 often take ages to get approved. Can you please email that bug report to me?

No the problem is still there in latest beta.
The problem is described better here:
http://forum.doom9.org/showthread.php?t=133974


Bugreport:
www.earselect.se/bugreport.txt

[rickardk]

Any advantage in not rewriting the timestamps? The frame skip/overlap seems worse than having a couple of ms off sync between audio and video

[rickardk]

Rainbow frames and glitches.

Originally Posted by madshi

Probably by demuxing video tracks and then remuxing them by using mkvtoolnix?


What does Ratatouille video have to do with eac3to? Generally I have always recommend against demuxing video and then remuxing it (which is currently the only way to mux Ratatouille to MKV). At least for h264 this can be problematic. I believe it's a better approach to use the Haali Matroska Muxer which gets along without fully demuxing the video first.

Yes but gdsmux can't remux some titles. And some titles that can be remuxed results in unsearchable mkvs. Sorry for bringing Ratatouille as an example (as it's remuxed without eac3to). But Million Dollar Baby is HD DVD and shows the exact same problem. But as the new eac3to does not rewrite timestamps with mkvmerge I guess I can get it working with eac3to.

So the blame is on mkvmerge for errors like "rainbow frames"?

[madshi]

Originally Posted by rickardk

No the problem is still there in latest beta.

Which problem? Can you please be more specific? The one with AVC titles? The one with VC-1? Or the one with mkvtoolnix not working?

Originally Posted by rickardk

www.earselect.se/bugreport.txt

This should already be fixed with v2.16.

Originally Posted by rickardk

Any advantage in not rewriting the timestamps? The frame skip/overlap seems worse than having a couple of ms off sync between audio and video

Have you read my (long) explanation?

Ideally the gap/overlap warnings should only occur if there are real gaps/overlaps (as is the case with Equilibrium). If I'd ignore the gaps with Equilibrium, audio sync would be totally lost and totally unrecoverable. It's not just some msec, it's some seconds with Equilibrium.

Anyway, those gaps/overlaps with the title you reported, are those still there with v2.16? I consider it a "bug" in eac3to, if such gap/overlap messages are appearing the way you reported. In the end eac3to should convert at least 99% of all movies without any such warnings. Equilibrium is the only title that I know where these warnings may "legally" occur. But I'm not sure. I've implemented this feature to be sure.

[madshi]

Originally Posted by rickardk

But Million Dollar Baby is HD DVD and shows the exact same problem.

Which problem does it show? Rainbow frames? Or non-seekable? Again you need to be more specific...

Originally Posted by rickardk

But as the new eac3to does not rewrite timestamps with mkvmerge I guess I can get it working with eac3to.

So the blame is on mkvmerge for errors like "rainbow frames"?

For rainbow frame with h264/AVC movies I tend to say "yes". It may not necessarily be the guilt of mkvmerge. It may be caused by bad demuxing or by a combination of strange effects related to the whole demux + remux process. No idea. But I think these problems should be solvable by using a different remuxing solution.

If you're talking about VC-1, things may be different. For your HD DVD VC-1 movie I'd like to have a sample, if the problem still occurs with v2.16.

[rickardk]

Sorry...
Million Dollar Baby HD DVD uses VC-1 and did with eac3to 2.13 end up with rainbow frames. Will try again with eac3to 2.16.

Yes I read you long explanation...thanks for taking the time to clear things out. But what I really wanted to know is if I should remux all my titles again using this new method?

Yes the problem with AVC titles like Ratatouille and Revolver is still there with latest beta. Don't know if VC-1 titles will work wthout introducing rainbow frames. But Ratatouille and Revolver did not work.

[nautilus7]

I am doing Million dollar baby now (v2.16)...

C:\Tools>eac3to F:\PEVOB1_1.EVO+F:\PEVOB1_2.EVO 2: dollar.mkv
EVO, 1 video track, 2 audio tracks, 2:12:35
1: Joined EVO file
2: VC-1, 1080p24 /1.001
3: E-AC3, 5.1 channels, 640kbit/s, 48khz, dialnorm: -27dB, 133ms
4: E-AC3, 5.1 channels, 640kbit/s, 48khz, dialnorm: -27dB, 133ms
Extracting primary video track...
Muxing video to Matroska...
Video has a gap of 9 frames at playtime 0:00:06.
Video track 2 contains 190727 frames.
eac3to processing took 50 minutes, 40 seconds.
Done.

-----

When it's done i will report.

[rickardk]

Great!

[madshi]

Originally Posted by rickardk

But what I really wanted to know is if I should remux all my titles again using this new method?

I don't think so. Maybe it would make sense to compare one movie wich new and old movie to check whether the new method works better or whether it's the same (or even worse - hopefully not!). But if the new method is not significantly better (which I don't think it is) there's no reason to redo everything.

[nautilus7]

Million Dollar baby is done, but result is not good. First of all i updated the log in my previous post.

I can't play it correctly with mpc (it's crap - full of glitches).
I can only decode VC-1 with WMVideo Decoder DMO right now and not ffdshow. (Something is wrong in my pc).
But, i tried wmp11 and it plays it correctly. Well almost correctly. If i seek the track it either play ok or not.

EDIT: I changed the video renderer in mpc from haali to vmr9 and now it behaves the same way like wpm11. I suppose the same combination of renderer/decoder is being used in both of them.

I guess a 50 MB sample would be ok?

[madshi]

Originally Posted by nautilus7

But, i tried wmp11 and it plays it correctly. Well almost correctly. If i seek the track it either play ok or not.

EDIT: I changed the video renderer in mpc from haali to vmr9 and now it behaves the same way like wpm11. I suppose the same combination of renderer/decoder is being used in both of them.

I guess a 50 MB sample would be ok?

Not sure now: Does it or does it not play correctly with VMR9? Is seeking the only problem?

A 50 MB sample is ok if the problem can be reproduced with that sample. I'm not talking about the Haali renderer, though. I'll not debug problems in the Haali renderer. Only VMR9 or EVR, please.

[nautilus7]

Well, with whole movie the problem is only seeking (vmr9). But with the sample playback is also a problem. If you find out out that the problem is not eac3to related, just skip it. Tell me if you can use any other decoder except VMVideo Decoder DMO with this sample, please.

Here's a 40 MB sample (it shrunk during upload ).

[rickardk]

Originally Posted by nautilus7

Million Dollar baby is done, but result is not good. First of all i updated the log in my previous post.

I can't play it correctly with mpc (it's crap - full of glitches).
I can only decode VC-1 with WMVideo Decoder DMO right now and not ffdshow. (Something is wrong in my pc).
But, i tried wmp11 and it plays it correctly. Well almost correctly. If i seek the track it either play ok or not.

EDIT: I changed the video renderer in mpc from haali to vmr9 and now it behaves the same way like wpm11. I suppose the same combination of renderer/decoder is being used in both of them.

I guess a 50 MB sample would be ok?

Did you use mkvmerge to add audio?
If so, please test to not run the file through mkvmerge and see if you still have glitches.

If you did not use mkvmerge. Please test run it through mkvmerge and check if it still plays fine with EVR or VMR9
Running it through mkvmerge often results in searchable files

[nautilus7]

No, no audio was added. I 'll run the mkv through mkvmerge to see what happens.

EDIT: Nothing changed.