eac3to - audio conversion tool

[madshi]

No more rainbow frames in Ratatouille, War and Revlover [...].

Perfect seekable.
:)

But CoreAVC decoding makes ffdshow TELL (not playback) the wrong framerate for 23.976fps sources.

eac3to HD DVD H264 muxing:
25fps

eac3to HD DVD H264 muxing (pulldown stripped with h264info)
25fps

eac3to Blu-ray H264 muxing:
25fps



mkvmerge HD DVD H264 muxing:
29.97fps

eac3to HD DVD H264 muxing (pulldown stripped with h264info)
23.976fps

mkvmerge Blu-ray H264 muxing:
23.976fps
I guess the last 3 entries were all supposed to read "mkvmerge"?

The default duration is however: 41.708ms (23.976fps) when opened in mkvinfo.
Not sure what's going on there. What is the exact DirectShow filter graph you're using and the exact setup of the filters?

The Machinist:
www.earselect.se/bugreport.txt

Seems like eac3to takes up all my memory. Allocates like 2GB then hangs.
:o The Machinist seems to have extremely rare IDR frames. I already thought that Equilibrium was extreme in that matter, but The Machinist seems to easily top Equilibrium. Anyway, it should be fixable on the cost of decreased performance. Currently I'm doing everything in RAM. It seems that I need to store some things on the harddisk temporarily... :(

[Jaja1]

eac3to v2.26 released* external raw h264/AVC tracks can now be muxed directly to Matroska
Does this mean I can use xport to demux a AVC blu-ray and remux xport's output to mkv with eac3to?

[rickardk]

Yes, mkvmerge for the last 3. Sorry.

haali splitter->coreavc->ffdshow->evr


ffdshow does nothing in this graph except reads the fps.
CoreAVC: preferred decoder, deinterlacing hardware, aggressive deinterlacing


Media Control then reads the frame rate from ffdshow to set the correct refresh rate.

[madshi]

Does this mean I can use xport to demux a AVC blu-ray and remux xport's output to mkv with eac3to?
Yes !

[madshi]

I've checked out the DTSWAV sample provided by nautilus7 and it looks awful to me. I see no good way to automatically detect whether the WAV file contains PCM or DTS. Also I don't have any information about how the DTS file is stored exactly in the WAV file. At least the DTS signature seems to be missing. So I really don't have much fun adding support for DTSWAV right now. Maybe I'll change my mind if someone has an exact specification?

[tebasuna51]

I've checked out the DTSWAV sample provided by nautilus7 and it looks awful to me. I see no good way to automatically detect whether the WAV file contains PCM or DTS. Also I don't have any information about how the DTS file is stored exactly in the WAV file. At least the DTS signature seems to be missing. So I really don't have much fun adding support for DTSWAV right now. Maybe I'll change my mind if someone has an exact specification?

Really I don't think you need support dtswav files because there are free tools to convert to standard dts (BeSplit, DtsParser,...) or to transcode directly to others formats (Foobar2000, BeHappy, ...).

BTW, some info:
the dtswavsample.wav from Nautilus7 have a wrong wav header (RiffLength and DataLenght wrong, AudioFormat 1 = pcm int). Seems Nautilus7 cut the firts bytes from a file 455114796 bytes long.

I see other dtswav with header with correct RiffLength and DataLenght but always AudioFormat 1 = pcm int.

When a wav is used like container the AudioFormat field must define the data format. If a soft found in a file, with wav extension, a correct pcm int header, can't know the data are dts compressed and output noise.

To use dtswavsample.wav with Foobar or BeHappy we need change the name to dtswavsample.dts

To decode a dtswav.dts first we need ignore the wav header (first 44 bytes) and now begin the dts, but the more frequent DTS signature is DCA_MARKER_14B_LE instead the standard DCA_MARKER_RAW_BE

See dca.h in libacodec lib:
#define DCA_MARKER_RAW_BE 0x7FFE8001
#define DCA_MARKER_RAW_LE 0xFE7F0180
#define DCA_MARKER_14B_BE 0x1FFFE800
#define DCA_MARKER_14B_LE 0xFF1F00E8


Or dts_syncinfo function in parse.c from libdts used in NicAudio decoder with AviSynth (BeHappy).

The data seems 14 bits little-endian instead 16 bits big-endian.

EDIT: There are many free samples at http://www.sr.se/cgi-bin/mall/artikel.asp?ProgramID=2446&Artikel=740607

[rickardk]

Maybe it's a problem with CoreAVC? I guess I could contact the developers?

When using other H264 decoders and ffdshow donwstreams the correct frame rate is read. (But that does not explain why a diffrent frame rate is shown when H264 is muxed with mkvmerge)

[madshi]

Maybe it's a problem with CoreAVC? I guess I could contact the developers?

When using other H264 decoders and ffdshow donwstreams the correct frame rate is read. (But that does not explain why a diffrent frame rate is shown when H264 is muxed with mkvmerge)
I don't know right now why eac3to h264 muxes show a different framerate compared to mkvtoolnix muxes in CoreAVC. I see no reason why that should be the case. But it might very well be a CoreAVC bug. Let me check that before you contact the developers, just to be safe...

[Thunderbolt8]

regarding coreavc, i might have a potential problem with the 'the illusionist' BD AVC stream: at one place in the movie theres a little glitch.
now the question is whether this could really be an eac3to muxing problem or not, since its really only this one instance of 5-6 frames in the whole movie, where it occurs, the complete rest is fine. so this could possibly be due to a ripping problem.

I demuxed the video with xport 1.01 and muxed it to .mkv using eac3to 2.26 (and remuxed with mkvmerge together with the audio afterwards, but doesnt matter, the problem is in both .mkv files). with coreavc I get this problem no matter whether I use eac3to or manually mux the video with mkvmerge only.
with ffdshow im not sure atm, because I deleted the mkvmerge video mux and therefore cant check how that result was. however, the glitch is not present when using eac3to to mux the video to .mkv.

so in the end it could as well be a ripping or coreavc decoder only problem, which I dont really mind to be frank since I actually dont use coreavc, only ffdshow. but since theres a slight possiblity it could nevertheless be a little problem of eac3to's muxing, which then could also occur when using ffdshow in other movies, I thought I mention it.

http://www.image-load.eu/out.php/i29771_snapshot20080303173521.PNG
http://www.image-load.eu/out.php/i29774_snapshot20080303173526.PNG
http://www.image-load.eu/out.php/i29778_snapshot20080303173530.PNG

[madshi]

Really I don't think you need support dtswav files because there are free tools to convert to standard dts (BeSplit, DtsParser,...) or to transcode directly to others formats (Foobar2000, BeHappy, ...).
If it's easy to support then I'll add it. Doesn't harm... :)

When a wav is used like container the AudioFormat field must define the data format. If a soft found in a file, with wav extension, a correct pcm int header, can't know the data are dts compressed and output noise.
Well, if the very first 4 bytes of the WAV data contain a valid DTS signature then I think it's safe to say that it's DTS and not WAV, right? I mean, the chance that a real WAV file randomly has exactly those DTS signature bytes in the first 4 bytes of the PCM data is extremely slim, especially because the beginning of a WAV file is usually silent. What do you think?

To decode a dtswav.dts first we need ignore the wav header (first 44 bytes) and now begin the dts, but the more frequent DTS signature is DCA_MARKER_14B_LE instead the standard DCA_MARKER_RAW_BE

See dca.h in libacodec lib:
#define DCA_MARKER_RAW_BE 0x7FFE8001
#define DCA_MARKER_RAW_LE 0xFE7F0180
#define DCA_MARKER_14B_BE 0x1FFFE800
#define DCA_MARKER_14B_LE 0xFF1F00E8

Cool - thanks!

Or dts_syncinfo function in parse.c from libdts used in NicAudio decoder with AviSynth (BeHappy).

The data seems 14 bits little-endian instead 16 bits big-endian.
:confused: Are the remaining 2 bits zeroed out?

[madshi]

regarding coreavc, i might have a potential problem with the 'the illusionist' BD AVC stream: at one place in the movie theres a little glitch.
now the question is whether this could really be an eac3to muxing problem or not, since its really only this one instance of 5-6 frames in the whole movie, where it occurs, the complete rest is fine. so this could possibly be due to a ripping problem.

I demuxed the video with xport 1.01 and muxed it to .mkv using eac3to 2.26 (and remuxed with mkvmerge together with the audio afterwards, but doesnt matter, the problem is in both .mkv files). with coreavc I get this problem no matter whether I use eac3to or manually mux the video with mkvmerge only.
with ffdshow im not sure atm, because I deleted the mkvmerge video mux and therefore cant check how that result was. however, the glitch is not present when using eac3to to mux the video to .mkv.

so in the end it could as well be a ripping or coreavc decoder only problem, which I dont really mind to be frank since I actually dont use coreavc, only ffdshow. but since theres a slight possiblity it could nevertheless be a little problem of eac3to's muxing, which then could also occur when using ffdshow in other movies, I thought I mention it.

http://www.image-load.eu/out.php/i29771_snapshot20080303173521.PNG
http://www.image-load.eu/out.php/i29774_snapshot20080303173526.PNG
http://www.image-load.eu/out.php/i29778_snapshot20080303173530.PNG
Does the problem also occur if you play the original movie with m2ts -> Haali Media Splitter -> CoreAVC?

[Thunderbolt8]

how can I test this, I tried to open the .m2ts with mpc, using coreavc, but the haali splitter icon does not appear in tray and the picture of the movie does not appear as well, the screen remains black, I cant skip forward or backwards and mpc basically crashed :S

edit: tried it with graphedit, opened the .m2ts file, the haali symbol was in tray and connected the video pin with the coreavc video decoder input pin, output was VMR0 renderer. if that was what you meant then yes, the same problem occurs there as well.

[madshi]

edit: tried it with graphedit, opened the .m2ts file, the haali symbol was in try and connected the video pin with the coreavc video decoder input pin, output was VMR0 renderer. if that was what you meant then yes, the same problem occurs there as well.
Then I can say that it's 99% sure that it's a bad rip and eac3to did not cause the artifacts.

[tebasuna51]

Well, if the very first 4 bytes of the WAV data contain a valid DTS signature then I think it's safe to say that it's DTS and not WAV, right? I mean, the chance that a real WAV file randomly has exactly those DTS signature bytes in the first 4 bytes of the PCM data is extremely slim, especially because the beginning of a WAV file is usually silent. What do you think?

Is easy if you expect this behavior but, of course, the wav players don't check this 4 first bytes.

:confused: Are the remaining 2 bits zeroed out?

From doc: ETSI TS 102 114 V1.2.1 (2002-12) DTS Coherent Acoustics:

"5.3 Synchronization
...
Note that, in order to make the harsh sound less unpleasant when DTS bit stream is mistakenly played back as PCM format, DTS now provides a 14-bit format that reduces the dynamic range from 16 to 14 bits. In this 14-bit format, DTS bit stream is stored only in the least significant 14 bits of a 16-bit word, the most significant 2 bits are not used, In case of this, SYNC is stored in three words: 0x1fff, 0xe800, and 0x07f."

Then the most significant 2 bits are zeroed, and ignored, but the data bitstream is the same, and:

dtswav_file_size = 44 + dts_file_size * 16 / 14

But this must be transparent for your soft if the decoder is compatible.

[madshi]

That helps, thank you!

[rickardk]

CoreAVC codec bug confirmed!
Can't wrap my head around the fact that mkvmerge+h264info (pulldown removed) gave the correct frame rate though.

But anyway... now I will continue to test H264 muxing out...

--------
Edited:
Not only confirmed...Actually they fixed it in latest version of CoreAVC.


--------
Enron - The Smartest Guy In The Room (HD DVD h264/AVC, 1080i60 /1.001 (16:9))
Another title that maxes my memory (in just 1 minute eac3to hangs).

[act.anon]

Enron - The Smartest Guy In The Room (HD DVD h264/AVC, 1080i60 /1.001 (16:9))
Another title that maxes my memory (in just 1 minute eac3to hangs).

I can confirm eac3to crashes on Enron, as well as LUCKY_NUMBER_SLEVIN

[mmoore99]

eac3to v2.26 released* external raw h264/AVC tracks can now be muxed directly to Matroska
Does this mean I can use xport to demux a AVC blu-ray and remux xport's output to mkv with eac3to?What would the eac3to command line be to remux the raw video tracks to mkv?

[madshi]

CoreAVC codec bug confirmed!
Can't wrap my head around the fact that mkvmerge+h264info (pulldown removed) gave the correct frame rate though.

But anyway... now I will continue to test H264 muxing out...

--------
Edited:
Not only confirmed...Actually they fixed it in latest version of CoreAVC.
Cool! So you properly get 23.976 now with eac3to - even if you don't use h264info, anymore?

Enron - The Smartest Guy In The Room (HD DVD h264/AVC, 1080i60 /1.001 (16:9))
Another title that maxes my memory (in just 1 minute eac3to hangs).
I can confirm eac3to crashes on Enron, as well as LUCKY_NUMBER_SLEVIN
I'll fix the memory problem in the next build.

What would the eac3to command line be to remux the raw video tracks to mkv?
"eac3to rawvideotrack.mpv movie.mkv"

The file extension of the raw video track shouldn't matter. eac3to should automatically detect the track correctly. This only works if the raw video track begins "cleanly" and not in the middle of a video frame, though.

[Mark_A_W]

madshi, with 2.26 is it now possible to go from a pair of .evo files to a .mkv file containing FLAC audio and the video in one step?

Or is it a two step process?

1. Video to .mkv and audio to FLAC (or whatever), same as before.

2. Remux separate files to a single .mkv file with eac3to.exe?

If you add the ability to extract chapters (like EVOdemux) and then write them back in again, you'll have all the bases covered for me....well...until I need subtitles, but that hasn't happened yet. :)

I'm trying the 2 step process now. If that's the way it works, I think it's batch file time!

Thanks for writing this...it's mildly useful...say for converting every HD-DVD I own to an easy to play format, thus saving me from a slow painful death, screaming at Powerdvd, and now I want to be your best mate forever ;)

[nautilus7]

2 steps as before. Nothing changed there and neither would in the near future, as far as i can tell.

[Thunderbolt8]

have to report back that my problems with rainbow frames from the first band of brothers Episode and also with babel are still present using eac3to 2.26. but they are only when using ffdshow (coreavc is fine) and its also the same when I use ffdshow to play the evo, so I guess these werent remuxing problems in the first place. I placed a small .evo sample in the ffdshow thread.

[madshi]

have to report back that my problems with rainbow frames from the first band of brothers Episode and also with babel are still present using eac3to 2.26. but they are only when using ffdshow (coreavc is fine) and its also the same when I use ffdshow to play the evo, so I guess these werent remuxing problems in the first place. I placed a small .evo sample in the ffdshow thread.
The Haali Media Splitter is pretty reliable in such a way that you should never see rainbow frames with h264 content as long as the source is clean and the decoder working correctly. The Haali Media Splitter is not perfect, it does have its problems, but rainbow frames with h264 content is not one of those (as far as I can say). So whenever you get rainbow frames when playing h264 EVO/m2ts files through the Haali Media Splitter, it's most probable that either the EVO/m2ts files are corrupt or that the decoder has a bug.

The situation is different with VC-1 content where the currently official Haali Media Splitter version still has some known problems which cause rainbow frames. Haali has already fixed all those problems in his source code but a new official version from him is not available yet. These problems are limited to VC-1, though.

[madshi]

eac3to v2.27 released

http://madshi.net/eac3to.zip

* fixed h264/AVC muxing crash with some movies (due to too high RAM usage)
* fixed missing frames at the end of the movie when doing h264/AVC muxing
* fixed non-working "eac3to -test"
This version should fix all currently known h264 muxing problems.

I've done some comparisons with the Equilibrium HD DVD. Here are the results:

mkvtoolnix older version: 800MB RAM
mkvtoolnix latest version: 25MB RAM, 27:15 min
haali splitter -> muxer: 800MB RAM, 22:20 min
eac3to v2.26: 800MB RAM, 20:36 min
eac3to v2.27: 25MB RAM, 21:55 min
The old mkvtoolnix version created an MKV which was out of sync with the audio. The MKV created by the latest mkvtoolnix version seems to be fine. Haali creates an MKV which is almost unseekable. eac3to v2.26 dropped the last few seconds of the credit. The MKV produced by eac3to v2.27 seems to be fine.

[Thunderbolt8]

thanks!

[rickardk]

Thanks alot!!

[Thunderbolt8]

I seem to have a problem with the AVC stream of the 'basic instinct' blu-ray, the muxing process basically stops at 16,1 mb of filesize and nothing else happens.
tried it with 2.26 and 2.27, its both the same, the only difference is that 2.26 notes 2 process digits "--", while 2.27 notes none or only 1.

need a sample (what size)?

[madshi]

I seem to have a problem with the AVC stream of the 'basic instinct' blu-ray, the muxing process basically stops at 16,1 mb of filesize and nothing else happens.
tried it with 2.26 and 2.27, its both the same, the only difference is that 2.26 notes 2 process digits "--", while 2.27 notes none.

need a sample (how big)?
Try to make a sample with the first 30MB of the m2ts file. Then check whether you can reproduce the problem with that m2ts sample. If yes, that sample size would be perfect. If the problem doesn't occur with that 30MB sample, you need to make it bigger. But if possible please make a m2ts sample. That's better than a raw AVC sample. Thanks!

[Thunderbolt8]

couldnt reproduce it with such a small filesize, needed 200mb for that. with 2.27 it stopped at about 2/3 of the process line, with 2.26 at the 2nd last digit.

heres the 200mb sample: http://www.sendspace.com/file/lp07ax

[mmoore99]

madshi, with 2.26 is it now possible to go from a pair of .evo files to a .mkv file containing FLAC audio and the video in one step?

Or is it a two step process?

1. Video to .mkv and audio to FLAC (or whatever), same as before.

2. Remux separate files to a single .mkv file with eac3to.exe?

If you add the ability to extract chapters (like EVOdemux) and then write them back in again, you'll have all the bases covered for me....well...until I need subtitles, but that hasn't happened yet. :)

I'm trying the 2 step process now. If that's the way it works, I think it's batch file time!

Thanks for writing this...it's mildly useful...say for converting every HD-DVD I own to an easy to play format, thus saving me from a slow painful death, screaming at Powerdvd, and now I want to be your best mate forever ;)Sorry to keep asking such basic questions (I actually have been following this thread since its inception and have read virtually every post), but the info in the 1st post regarding remuxing is pretty sketchy...Anyway, would the command line for doing step 2 as discussed above be:

"eac3to audio.flac video.mkv" assuming "video.mkv" was the specified video output from step 1?

[nautilus7]

madshi, with 2.26 is it now possible to go from a pair of .evo files to a .mkv file containing FLAC audio and the video in one step?

Or is it a two step process?

1. Video to .mkv and audio to FLAC (or whatever), same as before.

2. Remux separate files to a single .mkv file with eac3to.exe?

If you add the ability to extract chapters (like EVOdemux) and then write them back in again, you'll have all the bases covered for me....well...until I need subtitles, but that hasn't happened yet. :)

I'm trying the 2 step process now. If that's the way it works, I think it's batch file time!

Thanks for writing this...it's mildly useful...say for converting every HD-DVD I own to an easy to play format, thus saving me from a slow painful death, screaming at Powerdvd, and now I want to be your best mate forever ;)

2 steps as before. Nothing changed there and neither would in the near future, as far as i can tell.
Sorry about this... :o Step 2 isn't performed with eac3to. You have to mux audio and video with mkvtoolinx.

Therefore, what mmore99 asks isn't possible.

[Mark_A_W]

Sorry about this... :o Step 2 isn't performed with eac3to. You have to mux audio and video with mkvtoolinx.

Therefore, what mmore99 asks isn't possible.


Ahh, sorry I misunderstood the V2.26 changes.

My bad....

I'll combine the video and audio with Mkvmerge, as before.

Thanks

Mark

[madshi]

couldnt reproduce it with such a small filesize, needed 200mb for that. with 2.27 it stopped at about 2/3 of the process line, with 2.26 at the 2nd last digit.

heres the 200mb sample: http://www.sendspace.com/file/lp07ax
This is a combination of a badly authored movie and a bug in the Haali Matroska Muxer. The movie contains only very few "seeking points", which I consider bad authoring. And Haali's muxer stalls/freezes when it gets more than 1000 frames after each other without getting a new "seek point". That's why muxing freezes with this movie.

I've reported the bug to Haali, so hopefully he'll fix it in a future version of his muxer. Furthermore the next eac3to build will allow you to force "seek points" on every "I" frame of the movie. That will allow successfully muxing of the movie. However, it may theoretically happen that you'll get a little bit of image corruption sometimes when seeking. I rather guess the problem will not really occur in pratical life, though. So I think it should be fine to use that option with this movie.

[Thunderbolt8]

as long as it only occurs when seeking and will be gone once the stream starts to play again it shouldnt matter too much :P


regarding my AVC tests the results since eac3to 2.26 are as follows as far:

-band of brothers EP1: problems still present, but likely due to ffdshow
-babel: problems still present, but likely due to ffdshow
-basic instinct: have to test with 2.28 again
-equilibrium: looks fine
-ghost in the shell: looks fine
-oldboy: looks fine
-ratatouille: looks fine (though 1 time a mpc crash (splitter.ax), but could be due to seamless branching thing)

[madshi]

as long as it only occurs when seeking and will be gone once the stream starts to play again it shouldnt matter too much :P
I think it should be that way. Furthermore I think even when seeking with a bit of luck there will be no problem. It's just not fully "according to the spec" to set seek points on every I frame, but I don't really expect big problems with it... ;)

-ratatouille: looks fine (though 1 time a mpc crash (splitter.ax), but could be due to seamless branching thing)
Can you reproduce that crash? Does it always happen at the same place?

Edit: FWIW, rickardk told me via PM that Ratatouille worked just fine for him.

[Thunderbolt8]

im afraid I cant, at least not atm. it happend at one place when I jumped through the stream the first time. after that I already tried it again and jumped randomly back and forth several times, but no other crash happened so far. but as I said apart from that one incidence its fine. If I should encounter this problem again ill report back then.

[rickardk]

Yesterday I watched Ratatouille from start to finish without problem. I also tested seeking with no problem (jumping all over the timeline).

Tested again now. After 1 minute of jumping back and forth splitter.ax hanged. Tried againg but can't reproduce.

[madshi]

I have that hanging sometimes, too, when seeking h264 movies - even with EVO and m2ts files. I don't think I've seen this problem with VC-1 and MPEG2 content, though. I'm not sure where it comes from, but I'm quite sure that the MKV is not the cause of this. And that is the only thing I care about right now... :) It might be a bug in the Haali Media Splitter or a bug in the h264 decoder(s). As long as it's not a bug in eac3to, I don't care much... ;)

[rickardk]

Yes, I think the mkvs created by eac3to have nothing to do with this problem.

Just finished watching Babel from start to finish. Not a single problem. As thunderbolt said, it must be a ffdshow problem.

[Thunderbolt8]

it only appears when jumping anyway, but not when watching normally.

[madshi]

eac3to v2.28 released

http://madshi.net/eac3to.zip

* new "-seekToIFrames" switch makes Basic Instinct (h264) muxing work
This new switch works only for h264 movies and it's only meant to be used for h264 movies where muxing to MKV hangs (which should be rare). One such example is Basic Instinct. You can also try using this switch for movies which have a very bad seeking behaviour. This switch should improve seeking, but it does so by setting seek points to frames which might not be meant to be used as seek points. So it's theoretically possible that you'll get some image corruption for a short time after seeking. So use the switch on your own risk!

[Thunderbolt8]

thanks, will try it again tonight or tomorrow then!

btw. ive just encountered another problem, I tried to mux a mpeg2 TV source (1080i 29.97fps) to .mkv and nothing happens, the video hangs with v226 227 and 228 and nothing happens, the filesize remains at 0 byte. the source might be a bit tricky then it has resolution of 1440 as sequence display extension (means its displayed squeezed at least on my screen with mpv and vlc, though other people reported they dont have a problem with that). but this can be worked out via ReStream and I basically tried it to mux it 3 times with eac3to, one time with the video demuxed by xport, one time with video demuxed by tsremux and another time i tried it after removing that display extension, but in all 3 cases its the same.
considering the video stream itself, its also worthy to note that I cant jump back or forth in the .mpg stream, then mpc or vlc as well will crash (only straight playback works), but it gets fine as soon as the file is muxed to .mkv with mkvmerge for example.

I dont know in how far TV video source files are subject of eac3to, but still wanted to report it.

[madshi]

btw. ive just encountered another problem, I tried to mux a mpeg2 TV source (1080i 29.97fps) to .mkv and nothing happens, the video hangs with v226 227 and 228 and nothing happens, the filesize remains at 0 byte.
If you can reproduce the problem with a little sample, just send it to me.

[rickardk]

When muxing Enron - The Smartest Guy In The Room (HD DVD h264/AVC, 1080i60 /1.001) I get "Video has a gap of 1(/2) frames" for about 4-5 times for every second of the complete movie.

The mkv created by eac3to plays perfect however. But as soon as I try to mux audio into it with mkvmerge the resulting mkv hangs at start.

[madshi]

When muxing Enron - The Smartest Guy In The Room (HD DVD h264/AVC, 1080i60 /1.001) I get "Video has a gap of 1(/2) frames" for about 4-5 times for every second of the complete movie.

The mkv created by eac3to plays perfect however. But as soon as I try to mux audio into it with mkvmerge the resulting mkv hangs at start.
Can I get a sample, please? I think I should be able to fix the video gap complaints. But I'm not sure about the audio joining. I rather guess that it's not eac3to's fault. But I'll check it out.

[rickardk]

www.earselect.se/sample.evo

By using the .gaps file when doing a new reumx I'm now able to mux audio with mkvmerge and the resulting mkv plays.
But it stutter as hell (because of all "gap corrections" done by eac3to?).


To sum it up:
- eac3to reports alot of gaps
- the mkv created by eac3to will play perfect (smooth)
- when audio been muxed in with mkvmerge the resulting mkv will not play

- remuxing again using .gaps file
- the mkv created this time will stutter
- after audio is muxed the resulting mkv will play (but of course still stutters)

[Thunderbolt8]

If you can reproduce the problem with a little sample, just send it to me.
small samples seem to love me, this one here is 100mb -.-

http://www.sendspace.com/file/b8vsut

[Roscoe62]

I know this is a little off-topic, but has anyone managed to remux Spiderman 2 BR to mkv successfully and have the audio remain in sync? I gave up trying about 3 months ago when the last version of xport came out (1.00 I think). I just thought with Madshi on the case with his work on h264 processing in eac3to that maybe someone had managed it OK.

If someone has an answer please PM me as I don't want to enlarge this thread any further.

Sorry for the interruption.

[madshi]

@Roscoe62, it's not off topic as long as you're talking about remuxing the movie with eac3to. h264 remuxing is exactly what is the hot topic here in this thread right now. Why don't you give the new eac3to version a try with SM2? Chances are good that it will just work.

[shambles]

I know this is a little off-topic, but has anyone managed to remux Spiderman 2 BR to mkv successfully and have the audio remain in sync? I gave up trying about 3 months ago when the last version of xport came out (1.00 I think). I just thought with Madshi on the case with his work on h264 processing in eac3to that maybe someone had managed it OK.

If someone has an answer please PM me as I don't want to enlarge this thread any further.

Sorry for the interruption.

actually i was just about to post about this. about. sorry.

if the m2ts's are concatenated and then the truehd track xported, libav decoder will spit out 'lossless check failed' errors for each junction. likewise if they're demuxed individually and then eac3to run as '01.thd+02.thd+...' it will output the same errors. in both cases sync will be lost, doesn't matter whether libav or nero is used.

only way to keep sync is to demux them individually, then decode to wav files individually and then join them (i did this with wavewizard, and achieved perfect sync. don't know if if simple concatenation (copy /b) will work)