eac3to - audio conversion tool

[Thunderbolt8]

I guess that seamless branching might be the biggest challenge that still lies ahead to manage, but i'd guess that madshi would want to implement muxing from 'regular' blu-ray structure (meaning movies with only 1 main .m2ts file) for all 3 codecs, as it is now possible for .evo files, first, before dealing with movies wich are dealing with multiple .m2ts files, which need to be interconnected somehow.

nevertheless I wonder whether its possible to come closer to all that audio & video sync thing as it is currently the case when using xport and copy/b, by adding a specific delay for the number of joined parts and specific audio type and alternating the video framerate at the same time, we can already reach relative syncing, which is quite fine in almost any case I'd say, but I still wonder whether it might be possible to come as close to sync up to 1ms accuracy as it is possible with .evo muxing. its not that im dissatisfied with drmpeg's work he did with xport so far (I'd say that xport is quite flawless in the field its used in), I just wonder if this process can be more automatized and also the result be even more accurate ;)

[madshi]

I guess that seamless branching might be the biggest challenge that still lies ahead to manage, but i'd guess that madshi would want to implement muxing from 'regular' blu-ray structure (meaning movies with only 1 main .m2ts file) for all 3 codecs, as it is now possible for .evo files, first, before dealing with movies wich are dealing with multiple .m2ts files, which need to be interconnected somehow.
Exactly.

[Rectal Prolapse]

My understanding is that audio samples from one segment in a seamlessly branched Blu-ray title are allowed to overlap audio samples from the next segment (the player is supposed to know when to truncate the audio on either end). This would be very difficult to fix, as you would need to split the audio in one or the other segment at the exact point the video frame ends.

Also, a segment can begin with audio before the video starts - this can cause problems if you just use copy/b to join m2ts files as well.

[shambles]

it's actually not that difficult to fix if you know how much they overlap. if you decode them to pcm it's a simple calculation to find out how many bytes need to be snipped off.

[madshi]

Yep, when decoded to PCM it shouldn't be that hard to correct. But eac3to is not there yet with TS audio demuxing, so that's a bit too out of topic here at this point in time.

[nautilus7]

madshi there's a new eac3 libav decoder patch here (http://forum.doom9.org/showthread.php?p=1108304#post1108304). Have you seen it?

[Thunderbolt8]

im thinking about one thing, would it be possible for you to make a switch for internal rewriting of video timestamps?
I was thinking when you have a 25fps TV movie and you would like to remove PAL speedup, you would have to change the fps rate of the video as well of course. but as we know mkvmerge has some trouble with some files, be it .mpg or .h264 ones and when rewriting video timestamps at current stages you wont get around using mkvmerge. so im wondering would it be possible to include such an option for your internal muxers as well that they can rewrite the timestamps already so that this wouldnt need to be done with mkvmerge?
I dont know if this step has been done with mkvmerge all the time before anyway and only the muxing with your own rewritten tools (afaik yes), but do you think it would be possible to find a way of including such an option as well to get rid of possible faulty mkvmerge actions?

or is it maybe not possible any more than mkvmerge can screw anything up once the stream has been muxed into .mkv correctly by eac3to?

[madshi]

madshi there's a new eac3 libav decoder patch here (http://forum.doom9.org/showthread.php?p=1108304#post1108304). Have you seen it?
I believe that patch is for mplayer. I'm always pulling the latest ffmpeg E-AC3 decoder patch directly from SVN. That's the direct source. Also I'm quite sure that I have the latest TrueHD decoder patch implemented.

im thinking about one thing, would it be possible for you to make a switch for internal rewriting of video timestamps?
I was thinking when you have a 25fps TV movie and you would like to remove PAL speedup, you would have to change the fps rate of the video as well of course. but as we know mkvmerge has some trouble with some files, be it .mpg or .h264 ones and when rewriting video timestamps at current stages you wont get around using mkvmerge. so im wondering would it be possible to include such an option for your internal muxers as well that they can rewrite the timestamps already so that this wouldnt need to be done with mkvmerge?
I've already planned to implement that feature... ;)

[Thunderbolt8]

ive remuxed memento blu-ray (mpeg2; demuxed with xport and then muxed the video with eac3to) and encountered this bit of corruption which occurs for about half a second after seeking at most places, which you said could occur when using the -seektoiframes switch for h264 files for example(i didnt use the switch here of course). its in both, the .mkv from eac3to and the .mkv made afterwards by mkvmerge together with the audio.

apart from this short corrpution there is no problem, there are no actual video problems from what Ive seen, everything seems to be fine. maybe it could already be gone once direct remuxing from .m2ts files is supported. and as long as it only occurs at seeking I dont really mind.
the question is do you still would like to have a sample, maybe just out of interest or to improve things?
if yes, then it might get a bit tricky, because I cant take it from the beginning. of course I could, but at the beginning, the problem does not seem to be present, when just all cast names etc. are listed in blue letters on black background. the question then would be how to cut a sample from the mid of the stream which might still work and causes no problems just because of the way it was cut, which is quite often the case when I just cut random byte numbers.

[madshi]

maybe it could already be gone once direct remuxing from .m2ts files is supported.
I don't think so.

Does the same problem also occur when you mux the raw stream with mkvtoolnix or when you remux the m2ts with gdsmux?

the question is do you still would like to have a sample
Yes!

if yes, then it might get a bit tricky, because I cant take it from the beginning. of course I could, but at the beginning, the problem does not seem to be present, when just all cast names etc. are listed in blue letters on black background. the question then would be how to cut a sample from the mid of the stream which might still work and causes no problems just because of the way it was cut, which is quite often the case when I just cut random byte numbers.
m2ts files should normally be cuttable at a multiply of 192 bytes. Anyway, you can try multiple times. I just need a way to reproduce the problem.

[rickardk]

I remuxed Memento a couple of weeks ago. This corruption when seeking was just present when using libav for mpeg-2. Using libmpeg2 does not show this corruption when seeking. So it may be a decoder problem....

[Thunderbolt8]

Does the same problem also occur when you mux the raw stream with mkvtoolnix or when you remux the m2ts with gdsmux?
yes and yes

i guess rickard was right, the corruption is indeed gone when using libmpeg2. I made a post in the ffdshow thread about it.
heres the sample:

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


btw. I have another question: I demuxed the h264 stream from a TV source with xport and remuxed it with ec3to to .mkv. generally it looks all fine, while mkvmerge and gdsmux create a pretty mess from it so the result in general is pretty nice.
the video is reported as h264/AVC, 1440x1080 50i (20:11). I cant tell if 50i is correct, because I dont seem to need deinterlacing at all, but as I said it looks good with eac3to remuxing so I guess its fine. however, what I find a bit strange is that mpc properties report the video as follows: 1440x1080 (1963x1080). so does that 1963x1080 only refer to the AR relationship or to the actual resolution, meaning it could have been increased/stretched to 1963? im asking because I cant test it on my display, because my max. resolution is 1280x1024 and I wouldnt find it looking strange anytime later on, once I have a bigger display. so could it look strange on a display with 1920x1XXX resolution? I took screenshots from this and the original .ts, but both look the same. the .ts properties are reported by mpc as 1440x1088.

[xkodi]

@madshi

several interesting samples from "DTS 2008 HD Audio Demonstration Blu-ray":

1) first 5MB of the track, link: http://rapidshare.com/files/97795147/DTSHDMA50ch96kHz24bit.rar.html

"eac3to filename" reports:

"DTS Master Audio, 5.0 channels, 24 bits, 48khz"

but is it 96khz.

2) first 5MB of the track, link: http://rapidshare.com/files/97803882/DTSHDMA71ch.rar.html

"eac3to filename" reports:

"DTS Master Audio, 5.1 channels, 24 bits, 48khz"

but it is 7.1 channels. actually, all 7.1 DTS-HD MA files, that i've tried are reported as 5.1 channels.

===

"Dragon Tiger Gate Blu-ray" has both TrueHD 7.1 and DTS-HD MA 7.1 tracks, so it is very good for investigation of DTS-HD MA 7.1 decoding to full 7.1 channels. the first 5.1 channels decoded from the TrueHD 7.1 track with libav and the first 5.1 decoded from DTS-HD MA 7.1 with Sonic are byte by byte identical, which shows that the same uncompressed PCMs are used for both TrueHD 7.1 and DTS-HD MA 7.1, so thus TrueHD 7.1 decoded WAVs can be used as reference for what should be the result from decoding the DTS-HD MA 7.1 track.

here are the first 50MB from both tracks:

1) "Dragon Tiger Gate Blu-ray" TrueHD 7.1, first 50MB of the track: http://rapidshare.com/files/97801679/DTGBD.TrueHD7.1.rar.html

2) "Dragon Tiger Gate Blu-ray" DTS-HD MA 7.1, first 50MB of the track: http://rapidshare.com/files/97803625/DTGBD.DTSHD.MA.7.1.rar.html

hope those samples will be of huge help in finding way to decode DTS-HD MA 7.1 fully, because now we have DTS-HD MA 7.1 sample plus the uncompressed WAVs from which it is made (decoded from the TrueHD 7.1 track).

[nautilus7]

hope those samples will be of huge help in finding way to decode DTS-HD MA 7.1 fully, because now we have DTS-HD MA 7.1 sample plus the uncompressed WAVs from which it is made (decoded from the TrueHD 7.1 track).This wasn't the problem before. The problem is that there's none developing a dts-hd decoder, like with truehd and e-ac3.

@ madshi

A few months ago you said you were interested in 24 fps avc video. Do you still need a sample of such stream? I have a bluray with that kind of video.

[xkodi]

This wasn't the problem before. The problem is that there's none developing a dts-hd decoder, like with truehd and e-ac3.

eac3to reports DTS-HD MA 7.1 as 5.1 channels, same do the Sonic HDDemuxer, so probably both do the same check using the dts headers and probably that check is correct and then DTS-HD MA 7.1 are correctly seen as 5.1 channels. maybe that is how they should be seen and the side left and side right channels are in separate dts group, i.e. first dts group contains the first 6 channels plus the dts core for them and the second group contains the side left and side right channels. this is pure guess, i don't know nothing about dts and how the data are stored, but using the samples, someone with more knowledge may be able to find out and answer such questions.

[nautilus7]

Yes, eac3to would be able to report 7.1 channels correctly, but i was talking about decoding. madshi can not make sonic to decode 7.1. He has to develop his own decoder and i don't believe he would do such thing.

[xkodi]

Yes, eac3to would be able to report 7.1 channels correctly, but i was talking about decoding. madshi can not make sonic to decode 7.1. He has to develop his own decoder and i don't believe he would do such thing.

but maybe it is possible to use sonic to decode all 7.1 channels, because maybe eac3to and sonic hddemuxer report correctly that the channels are 5.1 and thus hddemuxer feeds the sonic decoder with only those 5.1 channels and that is why decodes only 5.1 channels, maybe there is a way to extract the rest two channels and feed the sonic decoder with them or something like that ...

[tebasuna51]

eac3to reports DTS-HD MA 7.1 as 5.1 channels, same do the Sonic HDDemuxer, so probably both do the same check using the dts headers and probably that check is correct and then DTS-HD MA 7.1 are correctly seen as 5.1 channels. maybe that is how they should be seen and the side left and side right channels are in separate dts group, i.e. first dts group contains the first 6 channels plus the dts core for them and the second group contains the side left and side right channels. this is pure guess, i don't know nothing about dts and how the data are stored, but using the samples, someone with more knowledge may be able to find out and answer such questions.

You are right, look this relevant info about your sample:
File: D:\Test\DTSHD_MA_50ch_96kHz_24bit_first5MB.dts
----------------------------------------- First Frame Info
Number of PCM Sample Blocks .: 15 ( 512 samples/frame)
Primary Frame Byte Size .....: 2011 ( 2012 bytes/frame)
Audio Channel Arrangement ...: 9 (5 C + L + R + SL + SR)
Core Audio Samp. Frequency ..: 13 (48 kHz)
Transmission Bit Rate .......: 24 (1536 Kb/s)
Embedded Dynamic Range Flag .: 0 (Not)
Low Frequency Effects Flag ..: 0 (Not present)
Encoder Software Revision ...: 7 (Current)
Source PCM Resolution .......: 6 (24 bits)
Dialog Normalization Param. .: - 0 dB
--------------------------------------------- Revised Info
Total Frames ......: 879
Duration ..........: 9,376 seconds. ( 0 h. 0 m. 9,376 s.)
Pad Bytes min./max.: 1672 / 5532 (bytes between frames)
------------------------------------------------- End Info
The core (primary) frame have a constant length of 2012 bytes and is 5.0 48 KHz with the source PCM (not the dts itself) 24 bits.

But between frames there are a variable (1672/5532) info with extra data referred to frequency (this case) or more channels (the other sample).

If the decoder (like my simple info tool) don't search/identify the extra data, only the core can be decoded. Eac3to can identify the extra data (but can't decode) and, I think, is send to the Sonic decoder but is ignored and only the core is decoded.

[xkodi]

@tebasuna51

what about:

http://rapidshare.com/files/97803625/DTGBD.DTSHD.MA.7.1.rar.html

because with this sample sonic decodes not the core, but the first 5.1 channels of the lossless DTS-HD MA and they are decoded correctly, byte by byte identical, verified that with the audio decoded from the same track in lossless TrueHD:

http://rapidshare.com/files/97801679/DTGBD.TrueHD7.1.rar.html

for which open-source decoder is available, that is capable to do 7.1 channels.

so is there any chance, that:

http://rapidshare.com/files/97803625/DTGBD.DTSHD.MA.7.1.rar.html

contains 3 streams: the dts core, the 5.1 lossless DTS-HD MA audio stream (seen and decoded by sonic) and additional 2.0 lossless DTS-HD MA audio stream. if so maybe it is possible to extract that additional 2.0 lossless DTS-HD MA audio stream like it is possible to extract the core and feed the sonic with it and thus decode the rest 2 channels and get the full 7.1 channels decoded.

[rickardk]

Problem remuxing Transporter 2 (I know...terrible movie...)

When trying to mux the raw MPEG-2 video stream (exported with xport) eac3to stops responding (but it never hangs....I left it on for over 90 minutes the first time I tried).

mkvmerge handle this without problems.

When I cut a 30MB sample eac3to successfully creates a mkv (without hanging) BUT it stutters alot using libav or libmpeg2 (Sonic video decoder does handle the mkv created by eac3to though).
Both libav and libmpeg handles the original m2ts, the mkv created by mkvmerge and the raw stream. So my conclusion is that something is wrong with the eac3to muxing.

www.earselect.se/stutter.m2ts

[madshi]

i guess rickard was right, the corruption is indeed gone when using libmpeg2.
Can you try some more MPEG2 decoders, please? There are about a dozen available. If the problem only occurs with one decoder then it's most probably a bug in that decoder. However, if you find more than 1 decoder which shows problems then it might be a real problem.

I demuxed the h264 stream from a TV source with xport and remuxed it with ec3to to .mkv. generally it looks all fine, while mkvmerge and gdsmux create a pretty mess from it so the result in general is pretty nice.
That's nice to hear! I would have expected gdsmux to handle the situation just fine. Generally gdsmux works well with h264 in my experience. However, I'm glad that eac3to worked well with a sample gdsmux choked on!

the video is reported as h264/AVC, 1440x1080 50i (20:11). I cant tell if 50i is correct, because I dont seem to need deinterlacing at all, but as I said it looks good with eac3to remuxing so I guess its fine. however, what I find a bit strange is that mpc properties report the video as follows: 1440x1080 (1963x1080). so does that 1963x1080 only refer to the AR relationship or to the actual resolution, meaning it could have been increased/stretched to 1963?
1440x1080 is the size the video is encoded in. However, the aspect ratio information in the stream seems to say "20:11". Consequently the video wants to be stretched a bit. If you displayed 1440x1080 without any stretching, it would be near to 4:3. The aspect ratio helps showing the video in the correct format. 1080 * 20 / 11 = 1963. That's where the strange number comes from.

im asking because I cant test it on my display, because my max. resolution is 1280x1024 and I wouldnt find it looking strange anytime later on, once I have a bigger display. so could it look strange on a display with 1920x1XXX resolution? I took screenshots from this and the original .ts, but both look the same. the .ts properties are reported by mpc as 1440x1088.
It doesn't matter which resolution your display has. The aspect ratio affects all display resolutions in a similar way. If it looks alright on your display then it will also look alright on a 1080p display. I'd like to get a sample from that video, though, if possible. Don't have a sample with 1440x1088 with h264 yet.

[rickardk]

Can you try some more MPEG2 decoders, please? There are about a dozen available. If the problem only occurs with one decoder then it's most probably a bug in that decoder. However, if you find more than 1 decoder which shows problems then it might be a real problem.


I did try this one with Cyberlink, Sonic, libmpeg2 and libav (just mentioned libmpeg and libav as I know Thunderbolt is a ffdshow guy ;) )

I think this is a known "problem" with libav.

[madshi]

1) first 5MB of the track, link: http://rapidshare.com/files/97795147/DTSHDMA50ch96kHz24bit.rar.html

"eac3to filename" reports:

"DTS Master Audio, 5.0 channels, 24 bits, 48khz"

but is it 96khz.
Thanks for the sample. Sonic reports (and decodes to) 96khz, so you're right, this is a 96khz sample. eac3to doesn't detect it correctly. The problem is that eac3to doesn't really know how to parse the additional DTS-HD blocks. I don't have a specification for the DTS-HD blocks, I've found out myself the very little bit of information that I have. I can just differ between Master Audio and High Resolution, but that's it. The remaining parameters are taken from the core. So if the core is 48khz (as is the case here) and the DTS-HD blocks add 96khz on top of that, eac3to just doesn't know that.

If anyone has any information about how to get information from the DTS-HD blocks, and can share them with me, please let me know.

2) first 5MB of the track, link: http://rapidshare.com/files/97803882/DTSHDMA71ch.rar.html
Are you sure that this is really 7.1? I have two 7.1 samples from NewLine Blu-Rays and they have a different header. So I thought I could detect Master Audio 7.1 by looking for the header the NewLine Blu-Ray tracks have. If this sample you uploaded is really 7.1 then I've no idea how I can properly detect 7.1 tracks.

Anyway, what we're talking about here are all pure cosmetical things. eac3to just passes the full information to the Sonic DTS-HD decoder. Sonic decodes all it wants to decode and eac3to grabs the full output. As a result your 96khz sample is handled 100% correctly by eac3to. The final WAV created by eac3to is properly flagged as 96khz. It's just eac3to's detection routine which can't always detect the correct information. But that has no effect at all on the decoding performance.

Sadly Sonic refuses to decode more than 6.1. Any 7.1 tracks are decoded as 5.1 (as is explained in the first post of this thread) and there's nothing I can do about it. eac3to does not limit the Sonic decoder in any way.

"Dragon Tiger Gate Blu-ray" has both TrueHD 7.1 and DTS-HD MA 7.1 tracks, so it is very good for investigation of DTS-HD MA 7.1 decoding to full 7.1 channels. the first 5.1 channels decoded from the TrueHD 7.1 track with libav and the first 5.1 decoded from DTS-HD MA 7.1 with Sonic are byte by byte identical, which shows that the same uncompressed PCMs are used for both TrueHD 7.1 and DTS-HD MA 7.1, so thus TrueHD 7.1 decoded WAVs can be used as reference for what should be the result from decoding the DTS-HD MA 7.1 track.

here are the first 50MB from both tracks:

1) "Dragon Tiger Gate Blu-ray" TrueHD 7.1, first 50MB of the track: http://rapidshare.com/files/97801679/DTGBD.TrueHD7.1.rar.html

2) "Dragon Tiger Gate Blu-ray" DTS-HD MA 7.1, first 50MB of the track: http://rapidshare.com/files/97803625/DTGBD.DTSHD.MA.7.1.rar.html

hope those samples will be of huge help in finding way to decode DTS-HD MA 7.1 fully, because now we have DTS-HD MA 7.1 sample plus the uncompressed WAVs from which it is made (decoded from the TrueHD 7.1 track).
Thanks! These samples are helpful. I'm a bit confused by why the first 5.1 channels are identical, though! Normally if there's 7.1 channels available and a decoder only outputs 5.1 then the output contains the back surround channels mixed into the surround channels. But well, maybe things are different with Master Audio 7.1...

[madshi]

The core (primary) frame have a constant length of 2012 bytes and is 5.0 48 KHz with the source PCM (not the dts itself) 24 bits.

But between frames there are a variable (1672/5532) info with extra data referred to frequency (this case) or more channels (the other sample).

If the decoder (like my simple info tool) don't search/identify the extra data, only the core can be decoded. Eac3to can identify the extra data (but can't decode) and, I think, is send to the Sonic decoder but is ignored and only the core is decoded.
No, the Sonic decoder actually makes full use of the extra DTS-HD blocks and fully decodes them. The only thing the Sonic decoder does not do (sadly) is output 7.1. But 96khz extensions and also lossless extensions etc are all fully and properly decoded.

[madshi]

I did try this one with Cyberlink, Sonic, libmpeg2 and libav (just mentioned libmpeg and libav as I know Thunderbolt is a ffdshow guy ;) )

I think this is a known "problem" with libav.
Thanks. In that case I can save some time by just ignoring this specific problem... :)

[rickardk]

Problem remuxing Transporter 2 (I know...terrible movie...)

When trying to mux the raw MPEG-2 video stream (exported with xport) eac3to stops responding (but it never hangs....I left it on for over 90 minutes the first time I tried).

mkvmerge handle this without problems.

When I cut a 30MB sample eac3to successfully creates a mkv (without hanging) BUT it stutters alot using libav or libmpeg2 (Sonic video decoder does handle the mkv created by eac3to though).
Both libav and libmpeg handles the original m2ts, the mkv created by mkvmerge and the raw stream. So my conclusion is that something is wrong with the eac3to muxing.

www.earselect.se/stutter.m2ts


Exact same problem with Flyboys. I did mux this one month ago with mkvmerge but I thought I should try more MPEG-2 titles when I found that Transporter did not work with eac3to.

[Thunderbolt8]

I'd like to get a sample from that video, though, if possible. Don't have a sample with 1440x1088 with h264 yet.
here it is: http://www.sendspace.com/file/swei9x

ive got another sample here from a 1080i mpeg2 TV source which eac3to doesnt accept, it says "There's a change from interlaced to progressive in the middle of stream."
I could reproduce it already with a 10mb sample, if you still need more then just tell.

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

[madshi]

A few months ago you said you were interested in 24 fps avc video. Do you still need a sample of such stream? I have a bluray with that kind of video.
I have a small sample from "Infernal Affairs" (or whatever the name was). If you have another 24.000 sample from a different movie, that'd be welcome.

[BLKMGK]

Madhsi, I've found eac3to to be of HUGE help to me converting (http://forum.doom9.org/showthread.php?t=135361) HD-DVD to formats I can watch on my HTPC. Your one tool nearly does the entire process save compression and has allowed me to convert my entire HD-DVD collection - good since my 360 went toes up.:rolleyes:

Now however I've purchased a BluRay drive and my first BluRay movie. As my HTPC is Linux based running XBMC (http://xbmc.org/forum/forumdisplay.php?f=52&order=desc) I'm inclined to convert this as well, it's not BD+ protected. I'm aware of xport and am working with it some now. But I'd like to ask, is there any chance we'll see a commandline like eac3to z:\BDMV\STREAM\00138.m2ts+z:\BDMV\STREAM\00139.m2ts 2: :\movie.mkv 3: d:\soundtrack.ac3 -640 -libav anytime soon? No disrespect to the xport developer but your tool has proven to be more than a little useful. Expanding it's usage to BluRay format files would be hugely appreciated. I've seen mention of using your tool on the audio portions already but having just one place to turn would certainly make life easier IMO.

Thoughts?

Regardless, you have my sincere thanks for having allowed me to so easily have converted my investment in HD-DVD for continued future enjoyment.:thanks:

[madshi]

I'm aware of xport and am working with it some now. But I'd like to ask, is there any chance we'll see a commandline like eac3to z:\BDMV\STREAM\00138.m2ts+z:\BDMV\STREAM\00139.m2ts 2: :\movie.mkv 3: d:\soundtrack.ac3 -640 -libav anytime soon?
This is already planned for a future version. I want to finish (make near perfect) HD DVD support first, though. So it might take another few weeks. But it shouldn't be too far off now.

[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.
I could not reproduce the 2nd problem (adding audio with mkvmerge makes it non-playable). But I can reproduce the first problem and honestly I'm not sure how to handle it *automatically*. It seems that eac3to's framerate detection is off for this movie. eac3to wants to mux it with 60i. But actually it seems to be 48i (or 24p?), which I find very strange. Anyway, with eac3to v2.29 you'll be able to use the new option "-24p" which will force eac3to to mux this movie with 24p/48i instead of 60i. That gets rid of the gap reports and also fixes the wrong runtime. The MKV eac3to v2.28 created was running too fast!

[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.
Problem remuxing Transporter 2 (I know...terrible movie...)

When trying to mux the raw MPEG-2 video stream (exported with xport) eac3to stops responding (but it never hangs....I left it on for over 90 minutes the first time I tried).
Exact same problem with Flyboys. I did mux this one month ago with mkvmerge but I thought I should try more MPEG-2 titles when I found that Transporter did not work with eac3to.
I think this is all one and the same problem. Please retry with v2.29. It might be fixed there. At least there's one MPEG2 muxing bugfix in v2.29 which also affects the samples both of you sent me.

ive got another sample here from a 1080i mpeg2 TV source which eac3to doesnt accept, it says "There's a change from interlaced to progressive in the middle of stream."
The problem with this is that the movie is encoded in "interlaced mode" in the beginning of the TS file, but then suddenly switches to "progressive mode" after a few milliseconds. eac3to currently cannot handle this. Maybe I'll add support for that in a future version if it's really needed. For now you can use either mkvmerge or you could try removing the first few milliseconds of the TS file. That should make it work with eac3to, too.

im thinking about one thing, would it be possible for you to make a switch for internal rewriting of video timestamps?
I was thinking when you have a 25fps TV movie and you would like to remove PAL speedup, you would have to change the fps rate of the video as well of course.
Added in v2.29. You can now slowdown 25fps PAL movies to 23.976fps by using the "-slowdown" switch and you can speedup 23.976fps movies to 25fps by using the "-speedup" switch. These are the same switches which were already used for audio operations.

[madshi]

eac3to v2.29 released

http://madshi.net/eac3to.zip

* added automatic audio gap/overlap correction for (E-)AC3, DTS(-HD) and LPCM
* options "-slowdown" and "-speedup" can now also be used for video muxing
* added support for muxing of EVO's secondary video track to MKV
* added "-24p", "-30p" and "-60i" options to overwrite detected h264 framerate
* fixed some MPEG2 muxing problems
* temporarily disabled "-stripPulldown" because vc1conv 0.3 is better
The "-24p", "-30p" and "-60i" switches should only be used for h264 muxing and only if the automatic framerate detection fails to work correctly.

The new audio gap/overlap correction should normally not do anything, as long as the EVO/VOB files are authored correctly. At least the correction did not do any action with any of my samples I've tried. However, if you find a sample where the correction actually does something, please let me know. I've implement this as a safety net. And it will probably be very useful later when dealing with seamless branching Blu-Ray titles where audio may actually overlap a little...

[nautilus7]

Thanks, again!

So to put it simply, the audio overlap detection finds whether a part of the audio is the same with the following one?

[madshi]

So to put it simply, the audio overlap detection finds whether a part of the audio is the same with the following one?
It doesn't look for identical audio data. It uses the timecode information of the container instead. Fortunately (unlike the video timecodes) the audio timecodes in EVO/VOB seem to be pretty stable. So if the audio timecodes say that there's "too much" audio data somewhere then I should be able to rely on that.

[Thunderbolt8]

thanks! in case there should still be problems with those last samples I sent to you, I'll report back.

[nautilus7]

It doesn't look for identical audio data. It uses the timecode information of the container instead. Fortunately (unlike the video timecodes) the audio timecodes in EVO/VOB seem to be pretty stable. So if the audio timecodes say that there's "too much" audio data somewhere then I should be able to rely on that.
Yes, i see. I actually thought it would be that way after i posted the question. :o

Regarding the strippulldown disabling, are you going to "see" how vc1conv is doing it and use its method in eac3to?

[madshi]

Regarding the strippulldown disabling, are you going to "see" how vc1conv is doing it and use its method in eac3to?
Not sure yet. Maybe.

[Thunderbolt8]

i got a question regarding the new h264 fps switches. are there actually h264 files at 30fps (30p) or 60i?
what about those 1440x1088 sample I sent you, eac3to reported it as 50i, although it seemed to me like 25p, because I couldnt spot any interlacing at playback. would it be wrong to use a 'p' switch on a 'i' stream and vice versa? so for that 50i or 25p whatever sample I sent you to slow it down to 23.976fps would I need the 24p switch then or something like 48i? im a bit confused :S

[madshi]

i got a question regarding the new h264 fps switches. are there actually h264 files at 30fps (30p) or 60i?
Sure.

so for that 50i or 25p whatever sample I sent you to slow it down to 23.976fps would I need the 24p switch then or something like 48i? im a bit confused :S
Have you missed the following sentence?

"The "-24p", "-30p" and "-60i" switches should only be used for h264 muxing and only if the automatic framerate detection fails to work correctly."

Just ignore these switches. You don't need them. For video PAL -> NTSC slowdown use the "-slowdown" switch.

[BLKMGK]

This is already planned for a future version. I want to finish (make near perfect) HD DVD support first, though. So it might take another few weeks. But it shouldn't be too far off now.

:thanks: I've been struggling with converting my first BluRay all day and this is terrific news! Trying to make heads or tails of this has been tough so being able to use something familiar will make life much easier. I look forward to this upgrade, I may even just stand down on buying\converting anymore video until I've got a clear path for conversion. Perhaps SlySoft will have tackeld BD+ by then and I won't have to be picky about titles\production houses too.

Thank you again for the hard work you've done, it really is appreciated.

P.S. Check your forum, if you've not already seen it someone tried to claim that some of your Delphi software was malicious - looks like a Sophos false due to hooking:rolleyes:

[Thunderbolt8]

Just ignore these switches. You don't need them. For video PAL -> NTSC slowdown use the "-slowdown" switch.
hm ok. but what if I wanted to slow down a video from which the fps detection fails? then the switch indicates the input fps rate of the source video, right?
and how could I find out in such a case if a h264 stream is 50i and not 25p, if it doesnt need any deinterlacing? or woudlnt it matter then?

[Yraen]

options "-slowdown" and "-speedup" can now also be used for video muxing

madshi,

Does the "-quality= " switch have any effect on the video muxing or is it only audio?

Thanks

[nautilus7]

Audio only. Affects resampling and slowdown/speedup quality. Default is 4, best quality.

[Thunderbolt8]

I guess I found a bug, I remuxed the 'memento' blu-ray (MPEG2) again with 2.29 and here the video was detected wrong as 1080p25 (its 1080p24 /1.001) and naturally the audio was out of sync with the audio in the final .mkv

[laserfan]

Fortunately (unlike the video timecodes) the audio timecodes in EVO/VOB seem to be pretty stable.About the video timecode issue, I had an impossible time getting a clean join of HD DVD Pan's Labyrinth, even after using your OffsetPTS tool. I ended-up setting it aside (my intent was to was to xvid the movie, not mkv).

Has anyone here been successful w/Pans HD DVD or am I a victim of pilot error? :o

[Thunderbolt8]

using eac3to it shouldnt be necessary to use offsetpts, but if you want to use evodemux or another demuxer you have to do it (and it also works for the studio canal version).

[nautilus7]

Which version of the hd dvd do you have? The french one? If this is the one, i will be able to report back in a days (maybe on Thursday).

EDIT: Thunderbolt8 caught me. So the french is working.

[madshi]

hm ok. but what if I wanted to slow down a video from which the fps detection fails?
When that happens and when red roses are raining from the sky then maybe you need to care about those options. In all other cases you don't. So just forget about them.

I guess I found a bug, I remuxed the 'memento' blu-ray (MPEG2) again with 2.29 and here the video was detected wrong as 1080p25 (its 1080p24 /1.001) and naturally the audio was out of sync with the audio in the final .mkv
Ooooops.

[madshi]

eac3to v2.30 released

http://madshi.net/eac3to.zip

* fixed wrong MPEG2 framerate (bug introduced in v2.29)