eac3to - audio conversion tool

[jmonier]

I have figured out how to mux seemlessly branched blu-ray's to mkv using eac3to and how to create truehd, pcm and ac3 audio tracks with eac3to. But what I haven't figured out is how to put them all back together into an mkv. I've tried using both Haali and Mkvtoolnix to put both the video file and audio files into an mkv, but both indicate that the pcm and thd+ac3 audio files are not supported media files. I've been successful using tsmuxer to put the files back together, but the truehd tracks won't play in my PCH A-110 even after remuxing with txremux. So, how do I put all of the files I've created using eac3to into an mkv container?

As I understand it, mkv does not support pcm or thd. For a lossless audio stream you need to convert them to flac. Or you can convert them to straight ac3.

[Skinleech]

Hhhm. I've not seen this message before, using Arcsoft to decode:

M2TS, 1 video track, 2 audio tracks, 4 subtitle tracks, 2:03:59
1: Chapters, 10 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: AC3, English, 5.1 channels, 640kbps, 48khz
4: DTS Master Audio, English, 7.1 (strange setup) channels, 24 bits, 48khz
(core: DTS, 5.1 channels, 24 bits, 1509kbps, 48khz)
5: Subtitle (PGS), Swedish
6: Subtitle (PGS), Danish
7: Subtitle (PGS), Norwegian
8: Subtitle (PGS), Finnish
Creating file "f:\sin.txt"...
CAUTION: Decoding this track with ArcSoft results in low volume.
[a04] Extracting audio track number 4...
[v02] Extracting video track number 2...
[v02] Muxing video to Matroska...
[a04] Decoding with ArcSoft DTS Decoder...
[a04] Encoding FLAC with libFlac...
[a04] Creating file "f:\sin.flac"...
[a04] The last DTS frame is incomplete and thus gets skipped.
[a04] The original audio track has a constant bit depth of 24 bits.
Added fps value to MKV header.
Video track 2 contains 178367 frames.
eac3to processing took 57 minutes, 10 seconds.
Done.

Sonic doesn't apply that error message, but I can only get 5.1 channels via that. Any idea? Thanks in advance.

[madshi]

both indicate that the pcm and thd+ac3 audio files are not supported media files.
MKV doesn't support TrueHD (yet?). You can use either FLAC or PCM. MKV does support PCM, but muxing it with mkvtoolnix only works through WAV. So you need to ask eac3to to create a WAV file and then mux that with mkvtoolnix. I don't know if mkvtoolnix can handle WAV files bigger than 2GB (4GB), though.

Downsampling 6ch AAC to 2 ch AAC did not work for me. Created a 6ch ACC instead (= did nothing)
That's a bug. Will be fixed in the next build. For now you can work around it by first doing "eac3to source.ac3 temp.wav -down2 -full" and then in an extra step "eac3to temp.wav dest.aac".

I've not seen this message before
Just do a search on this thread for the very warning message and you'll find the explanation you're looking for. (And maybe next time you can do that before posting... ;))

[Skinleech]

Just do a search on this thread for the very warning message and you'll find the explanation you're looking for. (And maybe next time you can do that before posting... ;))

Thanks. I did try searching, and it only brought up the 7000+ reply thread, not the posts related to the error.

I'll try again. :)

EDIT: Got it now; for some reason I didn't have the 'search this thread' option before, but it's there now.

[itsancho]

MKV doesn't support TrueHD (yet?). You can use either FLAC or PCM. MKV does support PCM, but muxing it with mkvtoolnix only works through WAV. So you need to ask eac3to to create a WAV file and then mux that with mkvtoolnix. I don't know if mkvtoolnix can handle WAV files bigger than 2GB (4GB), though. yep! ;) 2008-05-15 Moritz Bunkus <moritz@bunkus.org>

* mkvmerge: new feature: Improved support for WAV files bigger
than 4 GB which only contain a single DATA chunk and a wrong
length field for this DATA chunk (e.g. eac3to creates such files). and i'm waiting for TrueHD support, too...

[Jeff Flowerday]

Question for madshi or anyone smart like him:

SD DVDs with a mpeg2 video stream that is a combination of progressive and interlaced. I've seen it numerous times when I try to strip the pulldown flag. Just wondering what's going on, is there an acutal frame rate change? I assumed DVDs were all progressive on the source by nature.

[gillie]

Hoping someone can help.
I've been using the following process to produce .ts files of Blu-Ray rips which I can then play via my TVix M6500 "media streamer".

1. Rip Blu-ray disc to hard disk with AnyDVD HD
2. Use eac3to to extract video to .mkv and the audio to .dts or .ac3
3. Use tsMuxeR GUI to create .ts file container the video and audio streams

This process has worked fine for weeks but has now started creating a .ts file which has either no video playback or corrupted video playback. The audio is fine.

If I use tsMuxeR to extract the video and audio directly from the Blu-ray hard disk copy then the .ts file works okay. But using this method I'm unable to modify the audio output. My preference is to extract the lossless audio stream to DTS using eac3to and Surcode DTS encoder.

If I use MKVmerge to create a .mkv file of the same streams the output is fine, but my TviX box is rubbish with large .mkv files with high bit rates so this isn't an option for me.

Also tried using eac3to to extract the video to an elementary stream (.h264) then tsmuxed the streams into a .ts file and all works fine.

Looking at the mediainfo details for the .ts files which don't work it looks like something odd is going on. The "duration" of the .ts file is twice what it should be. But the individual .mkv and .dts files both have the correct duration. Think it may be the latest versions of eac3to which are producing odd .mkv files.

Would welcome anyones thoughts on this one.

[xkodi]

so, the studios are now using the DTS-HD MA 7.1 tracks with the "strange setup" on real movies too and not only on some BD demos.

[madshi]

SD DVDs with a mpeg2 video stream that is a combination of progressive and interlaced. I've seen it numerous times when I try to strip the pulldown flag. Just wondering what's going on, is there an acutal frame rate change? I assumed DVDs were all progressive on the source by nature.
This is a complicated topic. MPEG2 streams can be encoded as separate interlaced fields or as frames. A frame doesn't have to be progressive. It's very much possible to encode two interlaced fields in one frame. So even if an MPEG2 stream consists of frames, it can still be interlaced in nature. Now on top of that you can build the MPEG2 bitstream in such a way that only 24 frames per second are actually encoded, but the stream still plays at 60i, because there are flags in the stream which tell the decoder which fields are supposed to be repeated to do the 48i -> 60i pulldown.

In real life you can not trust the DVD bitstream encoding. You can not trust MPEG2 broadcasts, either. Both often switch between all the various bitstream encoding formats (60 interlaced fields, 30 frames, 24 frames with pulldown flags). Even if you have a stream with 24 frames and pulldown flags throughout the whole DVD, you still cannot always trust that everything is progressive. It's still possible that the wrong fields were encoded together into frames or that the pulldown flags are plain wrong. Because of this a good DVD player usually ignores all this stuff and simply decodes the stream as 60i and then uses a real video processing chip (e.g. HQV Reon) to figure out which of the fields belong together by analyzing the actual image content of all the fields.

So IMHO DVDs should never be treated as being progressive - unless you know for a fact that they are encoded perfectly.

Looking at the mediainfo details for the .ts files which don't work it looks like something odd is going on. The "duration" of the .ts file is twice what it should be. But the individual .mkv and .dts files both have the correct duration.
If the individual mkv and dts files seem to work correct on their own then why do you think the problem has anything to do with eac3to? It seems that the files produced by eac3to work perfectly fine on their own, but the TS file produced by tsMuxeR does not. So this looks like a tsMuxeR bug to me. And that's going to be my stance - unless you can find some evidence that something is wrong with the MKV and/or audio files produced by eac3to.

so, the studios are now using the DTS-HD MA 7.1 tracks with the "strange setup" on real movies too and not only on some BD demos.
It seems so. I'm not sure how many different movies are out there with such tracks, but at least one movie is. Unfortunately I'm not in a position to fix this. It's technically too complicated. The only proper solution would be for people who have licensed ArcSoft and who own such a problematic 7.1 Blu-Ray disc to report the problem to ArcSoft and ask them for a DTS-HD decoder fix.

[rica]

gillie ,
Haali and TSMuxer do not like VC1mkvs.
If your final container will be a TS, i'd advise this way:

Demux vc1 and audio with eac3to and remux to ts with TSMuxer.


If your final container will be an mkv, i'd advise this way:

Demux vc1 and audio with eac3to.
Open your vc1 with TSMuxer and remux into a ts container.
Convert ts to mkv with Graphstudio:
Haali splitter > Haali matroska muxer

Open this mkv file with MkvMergeGui and remux it with audio into an mkv.

(MkvMerge gui doesn't recognize raw vc1; so you have to convert it to mkv.
Haali splitter doesn't recognize vc1; so you have to convert it to ts)

[madshi]

If your final container will be an mkv, i'd advise this way
I disagree. What you suggest is complicated, time consuming and results in an MKV file which has suboptimal timestamps.

If the target container is MKV, there's no reason not to use eac3to for VC-1 muxing. Actually eac3to will give you optimal results. You can't get any better VC-1 MKV than those created by eac3to, as far as I'm aware.

Muxing to TS is another topic. It might be true that letting eac3to demux to a raw video stream is preferable if you want to create a TS with tsMuxeR. But if that's the case, it's caused by a bug in tsMuxeR and not by eac3to.

[xkodi]

It seems so. I'm not sure how many different movies are out there with such tracks, but at least one movie is. Unfortunately I'm not in a position to fix this. It's technically too complicated. The only proper solution would be for people who have licensed ArcSoft and who own such a problematic 7.1 Blu-Ray disc to report the problem to ArcSoft and ask them for a DTS-HD decoder fix.

yes, you mentioned before that patching DTS-HA MA headers is too complicated, because of the variable frame size if i remember correctly.

i doubt that Arcsoft will fix it soon, if fix it at all, e.g. Arcsoft do not decode correctly also all DTS-HD MA 7.1 16bit samples that i have in GraphEdit, but at least Arcsoft+eac3to decode them correctly.

[Thunderbolt8]

yep! ;) and i'm waiting for TrueHD support, too...
theres some ironie, mkvmerge can mux DTS-HD MA, but theres no directshow decoder for it yet. but ffdshow supports thruehd support (soon), yet we cannot mux it yet :p

[madshi]

i doubt that Arcsoft will fix it soon, if fix it at all
Not sure about that. Has anybody even brought this problem to ArcSoft's attention yet? Of course they won't fix it, if nobody reports it... ;)

[madshi]

theres some ironie, mkvmerge can mux DTS-HD MA, but theres no directshow decoder for it yet.
Doesn't the Sonic decoder work just fine? (Of course limited to 5.1, but still?)

The problem with TrueHD -> MKV muxing is simply that it's a totally separated codec. DTS-HD streams are muxed just like DTS streams are, so that was easy. Muxing TrueHD requires a whole new definition of how to do it exactly in MKV.

[rica]

But if that's the case, it's caused by a bug in tsMuxeR and not by eac3to.

Sorry but did i tell something like this?

I just wanted to share my experience; that's all.

which has suboptimal timestamps.



i disagree either.

[xkodi]

Not sure about that. Has anybody even brought this problem to ArcSoft's attention yet? Of course they won't fix it, if nobody reports it... ;)

actually, i believe that ArcSoft can't fix anything about DTS-HD MA decoding, they just buy the DTS-HD decoding library from DTS Labs and use it.

if you look with hex editor in dtsdecoderdll.dll (Arcsoft), CinemasterAudio.dll (Sonic) and dtshddec.dll (Corel WinDVD9) you can find the version of the DTS Labs DTS-HD decoding library with which the corresponding DLL is linked.

Arcsoft uses the most recent version of all of these 3 DLLs, but it's still old compared to the version that DTS Labs DTS-HD MAS suite version 1.6 is using.

so, i'm under the impression that when DTS Labs make newer version of the DTS-HD decoding library they don't supply it to their customers of the old versions of the library for free, otherwise i can't understand why Arcsoft, Sonic and Corel don't update the version they are using to the latest one, but instead they use old versions.

[Thunderbolt8]

Doesn't the Sonic decoder work just fine? (Of course limited to 5.1, but still?)
frankly said never tried it. i thought it was only used for eac3 decoding, didnt know I can use it to play dts-hd ma tracks as well. it plays them completely without drc, dialnorm; this is only applied for (e)ac3?

[gillie]

I disagree. What you suggest is complicated, time consuming and results in an MKV file which has suboptimal timestamps.

If the target container is MKV, there's no reason not to use eac3to for VC-1 muxing. Actually eac3to will give you optimal results. You can't get any better VC-1 MKV than those created by eac3to, as far as I'm aware.

Muxing to TS is another topic. It might be true that letting eac3to demux to a raw video stream is preferable if you want to create a TS with tsMuxeR. But if that's the case, it's caused by a bug in tsMuxeR and not by eac3to.

Thanks Madshi. I have to agree that using eac3to to create .mkv video stream has always worked flawlessly for me. Likewise using it to create DTS audio stream from lossless audio on original Blu-ray source works great as well. My preference would always be this route and then use MKVmergeGUI to create single .mkv file, however the DViX M6500 is absolutley hopeless at streaming .mkv files with high bit rates, i.e. 20Mbps+ hence my reason for using .ts which the DViX plays without a problem even though the video and audio steams are identical to those in the .mkv container.

Have any changes been made to eac3to recently which change the header info in an .mkv video stream which may now be confusing tsMuxeR?

[rica]

Think it may be the latest versions of eac3to which are producing odd .mkv files.

Who told this? Me?

[Nullity]

MKV doesn't support TrueHD (yet?).
yep! ;) and i'm waiting for TrueHD support, too...

I sent Mosu (the mkvtoolnix maintainer) an email about this a couple months ago, asking if he was planning on adding TrueHD support. His response was not quite what I was hoping for...

Probably not. I don't have specs for Dolby TrueHD, nor do I have such files.

Regards,
Mosu

I have no idea if he has changed his stance, but madshi, you have much greater influence in this area, perhaps you could convince him or give him a hand? :)

[madshi]

actually, i believe that ArcSoft can't fix anything about DTS-HD MA decoding, they just buy the DTS-HD decoding library from DTS Labs and use it.
May be true. But I'm not fully sure. E.g. do they get source code from DTS or just a static lib to link with? Also I'm not sure if it's really the decoder which is lowering the volume or if it's ArcSoft's own post processing...

it plays them completely without drc, dialnorm; this is only applied for (e)ac3?
Yes. BUT the decoder is slow and limited to 5.1. And I'm not sure if it accepts the Haali Media Splitter as input.

Have any changes been made to eac3to recently which change the header info in an .mkv video stream which may now be confusing tsMuxeR?
No, not at all. But I've heard multiple times that tsMuxeR generally doesn't like VC-1 MKVs. Don't know if that's true. And I really don't care much.

I have no idea if he has changed his stance, but madshi, you have much greater influence in this area, perhaps you could convince him or give him a hand? :)
The bigger problem is that there's no specification as of yet on how TrueHD should be stored in MKV. And it's not up to Mosu to make up such a specification himself.

[Momber]

Hi!
I just finished converting a True-HD track from HD DVD (Patch Adams) to lpcm and got this strange result:
[a04] Original audio track, L+R+C+LFE: constant bit depth of 16 bits.
[a04] Original audio track, SL+SR: constant bit depth of 24 bits.
How can a track have a bit depth of 16 and 24 bits at the same time?
How should I treat the resulting lpcm track for further processing - as 16 or 24 bit?

Greets
S.

[banker_rishad]

Can anybody help with eac3to guides like to how to%. Step by step guide. madshi plz advise

[xkodi]

May be true. But I'm not fully sure. E.g. do they get source code from DTS or just a static lib to link with?

static lib for sure, DTS Labs will never give them source code. also, i think that when you buy license for the DTS decoding lib, seems you get license only for particular version and not for the future updated versions, because for example let's take Sonic - in all version of their decoder DLL (the latest version of CinemasterAudio.dll 4.3.0.230 is only 1-2 months old) they always link to the same version of the DTS decoding lib and it is very old version.

same applies to Corel and Arcsoft with only the difference that Corel uses more recent version of the DTS-HD decoding lib than Sonic and Arcsoft uses more recent version than Corel, but still Arcsoft version is far from the latest that DTS-HD MAS uses. i look at this few month ago i and don't remember the exact version of the DTS lib that each DLL is using, but it was DTS-HD MAS > Arcsoft > Corel > Sonic. maybe, i will look at this again and post a table here in format "dll -> dts lib version".

[madshi]

I just finished converting a True-HD track from HD DVD (Patch Adams) to lpcm and got this strange result:
[a04] Original audio track, L+R+C+LFE: constant bit depth of 16 bits.
[a04] Original audio track, SL+SR: constant bit depth of 24 bits.
How can a track have a bit depth of 16 and 24 bits at the same time?
TrueHD always decodes to 24bit. A "16bit" TrueHD track also decodes to 24bit, but has the lower 8 bits zeroed out. So with this specific movie, obviously the surround channels have a true bitdepth of 24bit (all 24bits being made use of) while the other channels have the 8 lower bits zeroed out.

How should I treat the resulting lpcm track for further processing - as 16 or 24 bit?
If you want to conserve the full quality you should treat it as 24bit track. E.g. FLAC compression will still work very well. The final FLAC filesize will be somewhere between a typical 16bit and a typical 24bit FLAC size.

Of course the surround channels are slightly less important than the left/center/right channels. So you could also say since the more important channels are only 16bit, anyway, you can use "-down16" to convert the whole track to 16bit. However, doing this will result in eac3to applying dither to the main channels, too, unfortunately. So I'd recommend to keep the track as 24bit.

[Momber]

Thanks for your reply madshi!
I will treat it with pcm2tsmu as 24 bit... let's see how that works...

[siella]

I ask convert dts audio from here (http://forum.doom9.org/showthread.php?p=1218003#post1218003)

[n0mag!c]

TrueHD always decodes to 24bit. A "16bit" TrueHD track also decodes to 24bit, but has the lower 8 bits zeroed out.
So you could also say since the more important channels are only 16bit, anyway, you can use "-down16" to convert the whole track to 16bit. However, doing this will result in eac3to applying dither to the main channels, too, unfortunately.
Maybe you can implement "smart" "-down16"-switch behaviour then? Which will truncate lower 8 bits instead of making "standard TPDF dithering" for these channels? Or there are hidden disadvantages?

[madshi]

Maybe you can implement "smart" "-down16"-switch behaviour then? Which will truncate lower 8 bits instead of making "standard TPDF dithering" for these channels? Or there are hidden disadvantages?
That'd be hard to realize. If you do "-down16" eac3to doesn't know yet which channel has which true bitdepth. So eac3to would have to apply dithering. Only at the end of the whole processing eac3to would notice "ooops, some of those channels were only 16bit to begin with" and thus would have to redo the whole processing from the get go. That's quite complicated and honestly I don't really think it's worth the effort...

[Momber]

I will treat it with pcm2tsmu as 24 bit... let's see how that works...
It worked! Which is surprising, because usually if you feed 16 bit PCM into pcm2tsmu without the -i 16 option the result gets garbled. It didn't in this case however, which would indicate the lpcm track out of eac3to was true 24 bit after all. At least that's how I make sense of it...

Greets
S.

[Thunderbolt8]

madshi, could you please add a switch that just demuxes audio stream(s) in their state as they originally are (e.g. without applying any kind of delay and dialnorm removal etc.)? im hinting at those tv caps with corrupted ac3 (or dts) audio frames. in that case I always have to switch to xport to demux the track and then process it with delaycut. since this step cannot be avoided anyway, why not let eac3to demux them, 1 less program to use in between. there could be a message then like "just demuxing track without applying any delay or processing dialnorm etc." so that the user knows this stuff is still applied to the track and he then can get rid of it/fix it at a later time (e.g. after delaycut) if he likes to.

it just doenst make sense to go eac3to -> xport -> delaycut, when it could be eac3to -> eac3to -> delaycut. perhaps it would make sense to add a kind of -autoaudiodemux switch which then, in case that audio problems are detected and eac3to would have to abort, eac3to would directly start with the same command line again (or the audio track only then if it saves time and theres no thing as gaps), but this time then just as described as pure demuxing without any processing of that track.

[quantum]

..If the target container is MKV, there's no reason not to use eac3to for VC-1 muxing. Actually eac3to will give you optimal results. You can't get any better VC-1 MKV than those created by eac3to, as far as I'm aware.

Muxing to TS is another topic. It might be true that letting eac3to demux to a raw video stream is preferable if you want to create a TS with tsMuxeR. But if that's the case, it's caused by a bug in tsMuxeR and not by eac3to.

Is there any reason not to demux to raw video? I've found .TS works better on my Networked Media Tank so I've been going that way. I've been demuxing my Blu-rays and HD-DVDs to raw video and audio using eac3to, then remuxing with tsMuxer. So far I haven't visually noticed any issues. Am I losing timecodes this way?

[Momber]

I've checked The Descent and it's stored as 7.1, but BL and BR are identical and the case also sais 6.1. But still it's stored as 7.1.
I'm working on The Descent right now and eac3to gives me only 5.1 when demuxing to lpcm. I've also tried the -8 option but the output was the same: 5.1.
What am I doing wrong here?

TIA
S.

[madshi]

It worked! Which is surprising, because usually if you feed 16 bit PCM into pcm2tsmu without the -i 16 option the result gets garbled. It didn't in this case however, which would indicate the lpcm track out of eac3to was true 24 bit after all. At least that's how I make sense of it...
Well, if eac3to reports 16bit in its bitdepth statistics, that's just saying how many bits are filled with actual information. The bitdepth analyzation statistic does not say in which bitdepth the data is packaged. You can have 16 actual bits in a 24bit transport, or 20 actual bits in a 24bit transport, or 16 actual bits in a 32bit transport. That's all possible. A TrueHD track is usually something between 16-24 actual bits, but it's always a 24bit transport. eac3to does change the transport from 24bit to 16bit (by stripping the zero bytes) if the whole TrueHD track is only 16bit. So in such cases you have to use "-i 16" for pcm2tsmu. But for all other TrueHD tracks the transport is left at 24bit.

Or in other words: The pcm2tsmu switches must be set to the transport bitdepth and not to the number of bits which are non-zero inside of the transport. pcm2tsmu doesn't care how many bits are zero or non-zero.

madshi, could you please add a switch that just demuxes audio stream(s) in their state as they originally are
Igoring or working around errors has been requested a thousand times already and it's on my to do list - just like a dozen of other important things...

Is there any reason not to demux to raw video?
Depends on your final target. If you want to end up with an MKV then it's best to let eac3to create that MKV. If you want to end up with a TS, then you should do whatever works best with tsMuxeR. If tsMuxeR handles raw video streams better than MKVs then I don't see any problems using raw video streams. You do lose the timestamps created by eac3to in that case, but that's not really a problem - unless there are gaps/overlaps in the video track, which is extremely rare...

I'm working on The Descent right now and eac3to gives me only 5.1 when demuxing to lpcm. I've also tried the -8 option but the output was the same: 5.1.
What am I doing wrong here?
My English The Descent PCM track is 7.1 (reported as 6.1 on the back cover). Maybe you have a different version of The Descent? Does eac3to report 5.1 or 7.1 in the track listing?

[Momber]

My English The Descent PCM track is 7.1 (reported as 6.1 on the back cover). Maybe you have a different version of The Descent? Does eac3to report 5.1 or 7.1 in the track listing?
eac3to reports 7.1 and so does every other tool known to man ;)
The demuxed track is however only 5.1 (which also correlates with its size).

[madshi]

eac3to reports 7.1 and so does every other tool known to man ;)
The demuxed track is however only 5.1 (which also correlates with its size).
Can I have a small sample, please? 20MB should do - but please double check whether the problem also occurs with the sample. Thanks!

[Jeff Flowerday]

I've got some 6.1 DTS-ES and DTS Hi Res that I want to convert into flac. Is there anyway to tell it to create 7.1 flac by doubling that back channel?

Not sure if madflac isn't liking the resultant flac from eac3to or the resultant PCM from madflac isn't being liked by the audio renderer. Either way I'm getting no sound and graphedit won't render the mkv.

[madshi]

I've got some 6.1 DTS-ES and DTS Hi Res that I want to convert into flac. Is there anyway to tell it to create 7.1 flac by doubling that back channel?

Not sure if madflac isn't liking the resultant flac from eac3to or the resultant PCM from madflac isn't being liked by the audio renderer. Either way I'm getting no sound and graphedit won't render the mkv.
You can use the "-double7" option. Or maybe you can also use the ffdshow raw audio processor to do a similar thing at runtime? Not sure...

[Snowknight26]

When running a DTS track through eac3to just to get its info (eac3to file.dts), would it be possible to state whether it was padded or not? The only way to find out at the moment is to output a DTS file (eacto input.dts output.dts).

[Jeff Flowerday]

You can use the "-double7" option. Or maybe you can also use the ffdshow raw audio processor to do a similar thing at runtime? Not sure...

Not sure about ffdshow either, it's easier to just do convert to 7.1

Doing it right now, Thanks!!!

[kurt]

Can anybody help with eac3to guides like to how to%. Step by step guide. madshi plz advise
I don't know a specific guide for eac3to but there is at least this wiki: http://en.wikibooks.org/wiki/Eac3to/How_to_Use

Maybe it'll help you...

I've found .TS works better on my Networked Media Tank ...
that's because the NMT can decode TS/M2TS in hardware. mkv not. I'm also going over raw vc1 (from eac3to) to TS with tsmuxer and didn't experience any problems so far....

[madshi]

Stream consists of single encoded fields but PES packet header containing PTS spans always two fields.
Duration of clips is always a multiple of 40 ms (PAL).
I've found that while what you say is correct for your sample, it's not correct for German PAL HDTV broadcasts. Here every single interlaced fields seems to be stored in its own PES packet and has its own PTS value. So the duration is 20ms for these broadcasts.

I'm now using the average video PES duration. That seems to work pretty well.

When running a DTS track through eac3to just to get its info (eac3to file.dts), would it be possible to state whether it was padded or not? The only way to find out at the moment is to output a DTS file (eacto input.dts output.dts).
Done.

[madshi]

eac3to v2.79 released

http://madshi.net/eac3to.zip

* improved m2ts file joining overlap detection (mainly for interlaced video)
* vob/evo audio delay detection now uses "vobu start presentation time"
* program streams which are neither VOB nor EVO are now reported as "MPG"
* resampling is now automatically activated for AC3/DTS encoding, if necessary
* "Mersenne Twister" random number generator is used for dithering now
* zero padded DTS tracks are now displayed as such
* fixed: 32bit PCM conversion to floating point was broken
* fixed: with some (rare) movies first subtitle began after 50 minutes runtime
* only plugins with the extension *.dll are loaded now

[Snowknight26]

When Haali Media Splitter isn't installed and I specify .mkv as the output container for a video stream, this happens:

[v02] Extracting video track number 2...
[v02] Muxing video to Matroska...
[v02] Getting "Haali Matroska Muxer" instance failed.
----
The progress bar keeps going so I just cancelled it.

When I do have it installed, however, as I reported before, it still stops when the output file size is 2,752,512 bytes. Any way to track that issue down? Maybe a debug build of some sort?

[madshi]

it still stops when the output file size is 2,752,512 bytes. Any way to track that issue down?
Try muxing with gdsmux. Does that also freeze? Which video format is the movie in? Eventually there are too many frames without a new key frame. That usually makes the Haali Muxer freeze, unfortunately...

[Snowknight26]

It happens with any video, be it VC-1, H.264, etc. I've tried nearly a dozen sources.

With gdsmux, when I use the 1st file from Die Another Day (00130.m2ts [H.264] - Blu-ray is seamlessly branched) and I have all the tracks checked, gdsmux goes from 0-100% but the output mkv file size is 4,325,376 bytes. When I select only the video stream, it stopped at ~11% and the file size was the same. I checked any audio stream, and it did the same 0-100% thing, same output file size. Unchecked the audio stream once again to make sure, and it again stopped at 11.2% with an output file size of 4,325,376 bytes.

Tried it again with the Doomsday Blu-ray (00000.m2ts [VC-1]) and with all tracks selected, goes form 0-100% but the output is still 4,325,376 bytes. Unchecked the audio tracks, % stopped at 0.8 this time.

Tried it with the 2 Fast 2 Furious HD DVD (FEATURE_1.EVO [VC-1]), stopped at 8,462,336 bytes. The Apollo 13 HD DVD (PEVOB_1.EVO [VC-1]) stopped at 4,325,376.

Tried an mkv as a source file but it didn't work either.

Won't work with ES video tracks either but thats because there is 'no combination of intermediate filters [...] to make the connection.'

[madshi]

It happens with any video, be it VC-1, H.264, etc. I've tried nearly a dozen sources. Will test gdsmux though.
If it's source independent then it probably indicates a general problem with your PC/installation, because video muxing seems to be working for everyone else. My suggestion would be to uninstall Haali's Media Splitter, then cleanup the harddisk and the registry to remove all what might be left, then reinstall Haali. Maybe that helps, maybe not.

[Snowknight26]

I've done that several times now. Removed files, registry entries, etc, still nothing. (Edited my post above.)

[bigotti5]

Concatenating my Cam files work like a charm now.....:D
Thx

I've found that while what you say is correct for your sample, it's not correct for German PAL HDTV broadcasts. Here every single interlaced fields seems to be stored in its own PES packet and has its own PTS value. So the duration is 20ms for these broadcasts.

I'm now using the average video PES duration. That seems to work pretty well.

Yes - but video output length has to be a multiple of 40 ms