eac3to - audio conversion tool

[nautilus7]

It's been reported twice. v2.15 crashes with -test. A bug report is also uploaded.

[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.

[nautilus7]

It's a new feature! Some problems of the VC-1 stream, don't know exactly.

[rickardk]

Hangs on DTS-HD MA -> FLAC
Bugreport attached

[madshi]

You really should make a page where we could donate to support development. I will be the first in line...
I'm not sure yet how to handle this. Maybe I'll someday offer some extra functionality for a small donation/price while keeping the basic version free or something like that. Just offering a donation button isn't as easy as it may sound, since I also have to worry about taxes and that kind of stuff...

Ok, 117 titles remuxed. But I just got an alarming visit from my brother (he is helping me out). He talked to some guru online that said that some titles have glitches and rainbow frames when remuxed into mkv.
Probably by demuxing video tracks and then remuxing them by using mkvtoolnix?

One example that we checked was Ratatouille Blu-ray (AVC). At 40min and 30s there are some strange frames. Looks scambled. When watching the joined m2ts there is no problem.
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.

And I did Million Dollar Baby HD DVD (VC-1) yesterday. It did show the same problem. Is this a mux, codec or splitter problem?
Can you please retry with eac3to v2.16? If the problem still occurs with that version, can you please rerip and try again? If it still occurs I'd be happy about a little sample...

[madshi]

PS. Maybe stupid question: is possible to remove DRC and normaliz. from exists DTS track or I need source audio (DD HD, DTS HD, Flac, wavs etc.)?
Not sure what you mean exactly. You can remove dialnorm from a DTS track without decoding it simply by doing "eac3to source.dts dest.dts". This will remove dialnorm. But DRC cannot be removed this way. You have to make sure that DRC is not applied while decoding. eac3to does that for you if you use eac3to for decoding. BTW, most DTS tracks do not have dialnorm activated.

[madshi]

You are right, oggenc2 stop encoding at 4 GB limit unless we use raw data.

But use

RiffLength (offset 5) = 0xFFFFFF24 (instead 0x00000024)
DataLength (offset 41) = 0xFFFFFF00 (instead 0x00000000)

is always better. (I think)
Makes sense. Have added this to v2.16. Could you please test it? Thanks!

[madshi]

First thing i noticed with v2.15:

1: Joined EVO file
2: VC-1, 1080p24 /1.001
3: E-AC3, 5.1 channels, 640kbit/s, 48khz, dialnorm: -27dB
4: E-AC3, 2.0 channels, 192kbit/s, 48khz, dialnorm: -27dB
5: E-AC3, 2.0 channels, 192kbit/s, 48khz, dialnorm: -27dB
Extracting secondary video track...

It's a simple text output bug. Nothing to worry about. Should be fixed with v2.16 (I hope).

[madshi]

Maybe it's not a splitter problem. Because he just told me that Revolver could be muxed into mkv if video stream and audio stream muxed with gdsmux. But that gave a none searchable file. And it could not be opened with mkvmerge.
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/

Hangs on DTS-HD MA -> FLAC
Bugreport attached
The attachments in doom9 often take ages to get approved. Can you please email that bug report to me?

[madshi]

Hmm...
2.15 maybe a bit slower?

eac3to processing took 1 hour, 26 minutes.

Without rewriting the timestamps this one took 38 minutes with 2.13. Intel Quadcore at 3Ghz.
Hmmmm... This is probably caused by the (forced) background libav E-AC3 decoding (doing this to test the E-AC3 decoder). Can you please retry without E-AC3 decoding? How do the times compared then?

ffdshow reports it as 25fps...but audio and video sync.
ffdshow probably just guesses. The MKV files produced by the Haali Muxer don't have the fps stored in the header. That's the only disadvantage of skipping the timecode rewriting, AFAIK. It's not a big problem, though, since the fps value in the header is usually only used for purely informational purpose.

[madshi]

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]

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]

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]

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]

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

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.

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]

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.


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]

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?

www.earselect.se/bugreport.txt
This should already be fixed with v2.16.

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]

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... :)

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]

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]

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 (http://www.sendspace.com/file/g6xd5q) a 40 MB sample (it shrunk during upload :p ).

[rickardk]

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.

[rickardk]

Just did a new attempt with Born on the 4th of July.
2.15 gave a couple of frame gap/overlaps
2.16 gave less frame gap/overlaps problems
2.13 gave a smooth playable file with audio in synch (watched a couple of minutes at the start of the movie, att the middle and a few minutes before the end)

[madshi]

Just did a new attempt with Born on the 4th of July.
2.15 gave a couple of frame gap/overlaps
2.16 gave less frame gap/overlaps problems
2.13 gave a smooth playable file with audio in synch (watched a couple of minutes at the start of the movie, att the middle and a few minutes before the end)
Could I get a sample, please, which covers some of the gaps/overlaps? Thanks!

[Chumbo]

I was too slow to grab 2.15 before 2.16 came out. Would anyone be kind enough to provide a link to 2.15 via a site like rapidshare, mytempdir or other file hosting place please? Many thanks.

[rickardk]

Could I get a sample, please, which covers some of the gaps/overlaps? Thanks!

Yes I will make a sample of Sum of all fears too.
I never done a sample of an evo. How is it done?

[nautilus7]

I was too slow to grab 2.15 before 2.16 came out. Would anyone be kind enough to provide a link to 2.15 via a site like rapidshare, mytempdir or other file hosting place please? Many thanks.

Why do you want v2.15?

[madshi]

Yes I will make a sample of Sum of all fears too.
I never done a sample of an evo. How is it done?
Easiest way is to let EvoDemux rebuild and then abort rebuilding without deleting the file. A hexeditor would do, too.

[madshi]

EDIT: I changed the video renderer in mpc from haali to vmr9 and now it behaves the same way like wpm11.
That's strange. I'm getting garbled output even with VMR9. This is the very same effect I also had with "The Searchers". However, when I tried to rip audio from the Million Dollar sample, I got a message "the track is dirty" from eac3to. Is it possible that the rip is corrupt?

The garbled output appears on my PC with the MS VC-1 decoder and VMR9. The Sonic VC-1 decoder doesn't even show any picture. It just freezes. Had exactly the same symptoms with "The Searchers". That makes now 2 HD DVD VC-1 movies which my PC cannot handle at all. Fortunately all other VC-1 movies worked just fine for me until now. Not sure where the problems with those 2 movies are coming from. Maybe the VC-1 stream is incorrect somehow and PowerDVD's VC-1 decoder just knows a way to work around that somehow?

[dburckh]

I'm try to get a pulled down raw VC-1 stream out of an EVO with eac3to. I tried the -demux option and it said "no format was specified for the demuxer..." I did manage to get an mkv to work with 2.15, which is not what I want. Any pointers? Is this fixed in 2.16?

Why:

My ultimate goal is to get a VC-1/AC3/TS (or M2TS) stream out of an HD DVD. There seems to be a lot better support for this with the commercial players and hardware units. If I can get the raw streams, I think I can mux it to TS with ffmpeg. I'll write a muxer if I have to. :)

Thanks for your help and your awesome tool.

[nautilus7]

Well, with whole movie the problem is only seeking (vmr9). But with the sample playback is also a problem. You missed this...

That's strange. I'm getting garbled output even with VMR9. This is the very same effect I also had with "The Searchers". However, when I tried to rip audio from the Million Dollar sample, I got a message "the track is dirty" from eac3to. Is it possible that the rip is corrupt?

I tried something... I demuxed the vc-1 stream with evodemux and then muxed to mkv with eac3to. Result is playable (not the very begging though) but not seek able.

I also demuxed the audio with evodemux and run it through delaycut. The frames (e-ac3) 33 to 41 are corrupted.

Maybe the first seconds of the evo (original) is damaged/corrupted and they screw the whole file.

[Kumo]

how does the eac3to "speedup/slodown" feature work?does it stretch the intermediate wavs mono files(temporary encoded) or does it change the sample rate and re-sample to 44/48khz?is the result better than stretching the wavs mono files with an audio editor(like audition)?

[nautilus7]

I'm try to get a pulled down raw VC-1 stream out of an EVO with eac3to. I tried the -demux option and it said "no format was specified for the demuxer..." I did manage to get an mkv to work with 2.15, which is not what I want. Any pointers? Is this fixed in 2.16?

Why:

My ultimate goal is to get a VC-1/AC3/TS (or M2TS) stream out of an HD DVD. There seems to be a lot better support for this with the commercial players and hardware units. If I can get the raw streams, I think I can mux it to TS with ffmpeg. I'll write a muxer if I have to. :)

Thanks for your help and your awesome tool.
I don't know whether we are talking about the same error, but here's what i get:

C:\Tools>eac3to file.evo -demux
EVO, 1 video track, 1:16:47
1: VC-1, 1080p24 /1.001
Extracting primary video track...
The VC-1 pulldown remover didn't receive the format information.


C:\Tools>eac3to file.evo 1: file.vc1
EVO, 1 video track, 1:16:47
1: VC-1, 1080p24 /1.001
Extracting primary video track...
The VC-1 pulldown remover didn't receive the format information.

[nautilus7]

how does the eac3to "speedup/slodown" feature work?does it stretch the intermediate wavs mono files(temporary encoded) or does it change the sample rate and re-sample to 44/48khz?is the result better than stretching the wavs mono files with an audio editor(like audition)?
Re-samples back to original sample rate. Quality is very good as it takes a loooong time to complete. :p

[dburckh]

I don't know whether we are talking about the same error, but here's what i get:

C:\Tools>eac3to file.evo -demux
EVO, 1 video track, 1:16:47
1: VC-1, 1080p24 /1.001
Extracting primary video track...
The VC-1 pulldown remover didn't receive the format information.


C:\Tools>eac3to file.evo 1: file.vc1
EVO, 1 video track, 1:16:47
1: VC-1, 1080p24 /1.001
Extracting primary video track...
The VC-1 pulldown remover didn't receive the format information.


That's the one. Sorry for the ambiguity, I'm at work and didn't have the actual error in front of me.

[madshi]

I'm try to get a pulled down raw VC-1 stream out of an EVO with eac3to. I tried the -demux option and it said "no format was specified for the demuxer..."
Hmmmm... Seems to be a bug. Will fix that in the next build. For now try adding the "-keepPulldown" option. I think demuxing should work then.

I'll write a muxer if I have to. :)
A well working TS muxer would be quite lovely... :)

[madshi]

You missed this...
You're right, sorry.

I tried something... I demuxed the vc-1 stream with evodemux and then muxed to mkv with eac3to. Result is playable (not the very begging though) but not seek able.

I also demuxed the audio with evodemux and run it through delaycut. The frames (e-ac3) 33 to 41 are corrupted.

Maybe the first seconds of the evo (original) is damaged/corrupted and they screw the whole file.
I do think that the first seconds of the EVO file are damaged. But I'm not sure why seeking doesn't work with the rest of the movie. I've checked the VC-1 stream in the sample you uploaded for me and there seem to be enough key frames in there to make seeking work just fine.

Have you tried remuxing only the 2nd EVO to MKV? What happens then?

[madshi]

how does the eac3to "speedup/slodown" feature work?does it stretch the intermediate wavs mono files(temporary encoded) or does it change the sample rate and re-sample to 44/48khz?is the result better than stretching the wavs mono files with an audio editor(like audition)?
Stretching the wavs with an audio editor probably results in something quite similar to what eac3to is doing. But a lot depends on which algorithms are used exactly. There are good and bad ones. I'm not an expert on which algorithms are the best, but those eac3to is using (based on r8brain) were tested to belong to the better ones.

[nautilus7]

I do think that the first seconds of the EVO file are damaged. But I'm not sure why seeking doesn't work with the rest of the movie. I've checked the VC-1 stream in the sample you uploaded for me and there seem to be enough key frames in there to make seeking work just fine.

Have you tried remuxing only the 2nd EVO to MKV? What happens then?
I will try the 2nd evo right now.

(god, video/audio editing is trouble. But we wouldn't be here if we didn't like it. :eek: )


EDIT: 2nd evo (original & rebuilt with evodemux) results in 100% playable/seekable mkv with both haali and vmr9 renderers.

[nautilus7]

madshi, i cleaned the million dollar baby audio track and tried to process it with eac3to. The libav decoder crashed and probably this caused eac3to to crash too. I believe that shouldn't happen. Bug report (http://www.sendspace.com/file/uk1urh)

[madshi]

madshi, i cleaned the million dollar baby audio track and tried to process it with eac3to. The libav decoder crashed and probably this caused eac3to to crash too. I believe that shouldn't happen. Bug report (http://www.sendspace.com/file/uk1urh)
Ah well, maybe eac3to could catch the crash. But it's really a crash in the Nero decoder. It's not much of a difference if eac3to catches the crash or not. The processing won't work, anyway. Cleaning up didn't help, obviously. Did you use "fix" option? That's dangerous. Better use "silence" or "skip".

[mmoore99]

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.
Would you provide an example of how to do this?