eac3to - audio conversion tool

[papaleon]

Madshi:

Re: "The Bank Job" AVC/7.1 DTSHD

The AVC video track duration is 1:54:34.075

-core eac3to extraction yields a 1:52:01.749 DTS file

If I instead convert to AC3 with eac3to, we get a 1:54:34.075 file... and muxing this to the video gives perfect sync.

Obviously, a mux of the -core DTS and AVC video gives a very big video/audio sync problem.

But, I'd like to get the -core DTS and AVC together... thoughts?

hi!
are you shure the video is 1:54:34? Im getting this:

U:\BluRAY>eac3to The.Bank.Job
1) 00000.mpls, 00001.m2ts, 1:52:02
- h264/AVC, 1080p24 /1.001 (16:9)
- DTS Master Audio, English, multi-channel, 48khz
- AC3, French, multi-channel, 48khz
- AC3, English, stereo, 48khz

U:\BluRAY>eac3to The.Bank.Job 1)
M2TS, 1 video track, 3 audio tracks, 3 subtitle tracks, 1:52:02
1: Chapters, 17 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: DTS Master Audio, English, 7.1 channels, 16 bits, 48khz
4: AC3, French, 5.1 channels, 640kbit/s, 48khz, dialnorm: -27dB
5: AC3, English, 2.0 channels, 224kbit/s, 48khz, dialnorm: -27dB
6: Subtitle (PGS), English
7: Subtitle (PGS), English
8: Subtitle (PGS), Spanish

and no problems what so ever when muxing video with flac track...

:edit

I can see now that i have deleted all the files in the stream folder except the 00001.m2ts, maybe this is why im not having any problems...
Try to use eac3to with only this file, maybe it helps....

[sehgal.v7]

@scarbrtj
Original Blu Ray Info--
The Bank Job (2008) Length 1:52:01 // Size -19,677,437,952

[madshi]

So, I'm trying to convert CJ7 (the newish Steven Chow movie) to MKV and running into quite a bit of difficulty.

It's a multi-part (But I've dealt with that before by muxing together with tsmuxer.) However, there's some problem with the streams, when running tsmuxer or eac3to I get many alerts of the type

The program channel mapping changes in the middle of the stream.
Please retry with the next eac3to build. Or if you're in a hurry, you can eventually work around the problem by deleting (or renaming) the last m2ts part that is listed by eac3to for the movie. That last part is probably very small, right?

Re: "The Bank Job" AVC/7.1 DTSHD

The AVC video track duration is 1:54:34.075
How did you get this duration information?

Obviously, a mux of the -core DTS and AVC video gives a very big video/audio sync problem.
Which software are you using exactly to mux video and audio together? And into which container are you muxing them?

[sehgal.v7]

@Madshi
Why is there difference in Dolby Digital Plus Demuxing with Eac3to AND TSRemux or TSMuxer?? (Except Last incomplete Frame?)
Is it coz of Audio Delay or dialog normalization?

[nautilus7]

Because eac3to removes Dialog Normalization by default, while others don't.

If you're worried about audio bit perfectness using eac3to and other tools, I can assure that a lot of people have test it before you. And everything is fine.

[xkodi]

If you're worried about audio bit perfectness using eac3to and other tools, I can assure that a lot of people have test it before you. And everything is fine.

second this.

[sehgal.v7]

Thanks Broz!!

[madshi]

Why is there difference in Dolby Digital Plus Demuxing with Eac3to AND TSRemux or TSMuxer?? (Except Last incomplete Frame?)
Because eac3to removes Dialog Normalization by default, while others don't.
And that's an important thing to note, if you think about it:

There is a difference between:
(1) keeping compressed bitstream bit perfect and
(2) making sure that decoded data is bit perfect.

What we want above all is (2). But in order to achieve (2) we sometimes have to sacrifice (1). E.g. we have to remove dialnorm to get bit perfect audio decoding. eac3to does a lot of modifications to compressed bitstreams. Dialnorm is removed, zero padding is removed, DTS ES bitstream errors are fixed, DTS bitdepth is patched etc. All this destroys bit perfectness of the compressed bitstream, but makes sure that decoded data is bit perfect.

Now the same thing is valid for video as well: eac3to does some modifictions to the compressed bitstream. E.g. pulldown is stripped, sequence end codes are removed, filler data is removed (and some more modifications to come). Some of this has a positive effect on decoding (e.g. pulldown removal can get rid of judder with some decoders), some of this just saves space (removal of filler data), but none of this has any negative effect on decoding. So that's why we shouldn't worry so much about bit perfectness of compressed bitstreams. What you should worry about is bit perfectness of decoded data. So manipulations in the compressed bitstream are ok, as long as these manipulations improve (or at least don't negatively effect) the decoding performance. This is also the reason why I was never worried about h264 bitstream not being bit perfect (see last 2 pages of discussions).

Sorry for the long rant. These things just became clear to me, so I wanted to write them down to give us all a bit more piece of mind when finding differences in compressed bitstreams.

[rica]

Madshi, please check mercury's file:

http://rapidshare.com/files/139623098/VC-1Test.m2ts.html

This is interesting?

C:\>eac3to\eac3to.exe "C:\Users\rica\Desktop\VC-1Test.m2ts" "C:\Users\rica\Desktop\new.dts"
Access is denied.


http://img300.imageshack.us/img300/1717/mercurysx9.th.png (http://img300.imageshack.us/my.php?image=mercurysx9.png)

thanks.

[madshi]

This is interesting?
No. Your eac3to download or your harddisk is probably corrupt. Delete "eac3to.exe", empty your browser cache and redownload. That will most likely fix the problem. You may also want to do a scandisk.

[rica]

Thanks a lot!

[scarbrtj]

hi!
are you shure the video is 1:54:34? Im getting this:

U:\BluRAY>eac3to The.Bank.Job
1) 00000.mpls, 00001.m2ts, 1:52:02
- h264/AVC, 1080p24 /1.001 (16:9)
- DTS Master Audio, English, multi-channel, 48khz
- AC3, French, multi-channel, 48khz
- AC3, English, stereo, 48khz

U:\BluRAY>eac3to The.Bank.Job 1)
M2TS, 1 video track, 3 audio tracks, 3 subtitle tracks, 1:52:02
1: Chapters, 17 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: DTS Master Audio, English, 7.1 channels, 16 bits, 48khz
4: AC3, French, 5.1 channels, 640kbit/s, 48khz, dialnorm: -27dB
5: AC3, English, 2.0 channels, 224kbit/s, 48khz, dialnorm: -27dB
6: Subtitle (PGS), English
7: Subtitle (PGS), English
8: Subtitle (PGS), Spanish

and no problems what so ever when muxing video with flac track...

:edit

I can see now that i have deleted all the files in the stream folder except the 00001.m2ts, maybe this is why im not having any problems...
Try to use eac3to with only this file, maybe it helps....


And @ sehgal

I can see that the original 00001.m2ts file is 1:52:01. But a "funny thing happened on the way to the bank" as they say. If you take out the individual elementary AVC stream... you get a file 1:54:34 in length. I am using tsremux or tsmuxer to do that; or, if you mux into mkv with eac3to you get 1:54:34 as well. And then I used eac3to to make an AC3 from the DTS-HD track. That AC3 elementary stream is 1:54:34 in duration.

When I mux the AVC and AC3 files together into M2TS... I am back to a 1:52:01 file!

So, this type behavior happens for me all the time with DTS-HD files, and tsmuxer or tsremux seem no better to me at getting the timing of the -core file right. I like passing the DTS bitstream via SPDIF to my receiver, and the only way I have gotten this to work is to use MKV to wrap the DTS in.

I'd love to know how other guys are getting DTS cores and playing them back via SPDIF.

[73ChargerFan]

I'd love to know how other guys are getting DTS cores and playing them back via SPDIF.
eac3to with -core option, and spdifer with mpc-hc

mpc-hc built in dts filter doesn't work with 1536 streams on mine and on other's setups, and spdifer at sourceforge is perfect

[Kurtnoise]

Houston, we've got a problem...

http://i433.photobucket.com/albums/qq59/Kurtnoise/eac3to257.png

[menlvd]

Houston, we've got a problem...

http://i433.photobucket.com/albums/qq59/Kurtnoise/eac3to257.png

Houston reporting: -quality=0.0-0.99 :)

[madshi]

I can see that the original 00001.m2ts file is 1:52:01. But a "funny thing happened on the way to the bank" as they say. If you take out the individual elementary AVC stream... you get a file 1:54:34 in length. I am using tsremux or tsmuxer to do that; or, if you mux into mkv with eac3to you get 1:54:34 as well. And then I used eac3to to make an AC3 from the DTS-HD track. That AC3 elementary stream is 1:54:34 in duration.

When I mux the AVC and AC3 files together into M2TS... I am back to a 1:52:01 file!
Your way of reporting things is not very helpful because you leave out a lot of details. Some examples:

(1) "If you take out the elementary AVC stream... you get a file 1:54:34 in length"

Where did you get this runtime information from? Normally it's not possible to get a runtime information from a demuxed AVC file cause AVC is variable bitrate, so you can only guess the runtime.

(2) "if you mux into mkv with eac3to you get 1:54:34 as well"

If you mux what? The AVC track demuxed by TsMuxer/TsRemux? Or the m2ts file? Or did you use eac3to's Blu-Ray structure parser? In the latter case eac3to might have joined more than just m2ts parts to produce the MKV.

(3) "That AC3 elementary stream is 1:54:34 in duration"

Sais who? eac3to? Or your media player?

I can't help you any further if you don't post more detailed reports. FWIW, most DTS parsers don't handle the core of DTS-HD tracks well. They show wrong runtime information. eac3to should show the correct runtime for Blu-Ray/HD DVD DTS-HD extracted core tracks.

[Kurtnoise]

Houston reporting: -quality=0.0-0.99 :)
aaa...I knew that I missed something. :D Thanks.

[deacon crusher]

Madshi

I'm going through a manual process, extract each file and then recombine, so far so good.

To answer your question, yes that last m2ts is tiny.

I'll be happy to retry this process when you have a new eac3to available. One thing I can't do with my manual process is recombine the sup files into one so I'll hopefully get that done when you try your new version.

Awesome tool and if any further details would be useful, I'd be happy to provide them.

Thanks

[QUOTE=madshi;1174297]Please retry with the next eac3to build. Or if you're in a hurry, you can eventually work around the problem by deleting (or renaming) the last m2ts part that is listed by eac3to for the movie. That last part is probably very small, right?

[sehgal.v7]

@Madshi
If source is having discontinuity, what does Eac3to does? Does it delete it or put empty block thr?
[v01] The source seems to be damaged (discontinuity) at file pos 2059182612.
[v01] The source seems to be damaged (discontinuity) at file pos 2094306464.
[a02] The source seems to be damaged (discontinuity) at file pos 2094651444.

[scarbrtj]

Your way of reporting things is not very helpful because you leave out a lot of details. Some examples:

(1) "If you take out the elementary AVC stream... you get a file 1:54:34 in length"

Where did you get this runtime information from? Normally it's not possible to get a runtime information from a demuxed AVC file cause AVC is variable bitrate, so you can only guess the runtime.

(2) "if you mux into mkv with eac3to you get 1:54:34 as well"

If you mux what? The AVC track demuxed by TsMuxer/TsRemux? Or the m2ts file? Or did you use eac3to's Blu-Ray structure parser? In the latter case eac3to might have joined more than just m2ts parts to produce the MKV.

(3) "That AC3 elementary stream is 1:54:34 in duration"

Sais who? eac3to? Or your media player?

I can't help you any further if you don't post more detailed reports. FWIW, most DTS parsers don't handle the core of DTS-HD tracks well. They show wrong runtime information. eac3to should show the correct runtime for Blu-Ray/HD DVD DTS-HD extracted core tracks.

If you just put the AVC file in mkv, that's how I'm getting duration information... and I'm using the "file info" feature in AVIMuxgui to get that. When I talk about muxing with eac3to here, I am specifically talking about just putting the AVC into mkv. All my timing information is from AVIMuxgui.

Here is the specific workflow, and what I experienced. I extracted an AVC elementary stream (with tsremux, and tsmuxer; tried both). I extracted a core DTS elementary stream with eac3to. I muxed those with mkvmerge. The audio/video was badly out of sync. I used eac3to to make an AC3 of the DTS-HD 7.1 track. I muxed again with mkvmerge. The audio/video were perfectly in sync. (A check of times of the audio tracks revealed the DTS core track to be a couple seconds shorter than the AC3 track, and that the AC3 track matched to the millisecond the duration of the video track.)

Now... as some additional info... if you extract a -core DTS file with eac3to, versus if you convert to .wavs and then make a DTS file from those .wavs with eac3to (using Surcode), you will get files of slightly different time lengths.

("How do you get time lengths?"... mux to mkv or mka and use AVIMux gui...)

And, in my limited experience, the time of the eac3to/SurCode-generated DTS file will always match the time of the video track (whether that be AVC or VC-1... can't remember a MPEG-2/DTS combo), whereas the eac3to/core DTS file will not. That seems problematic to me. I use spdifer as my DTS "decoder."

[boombastic]

@Madshi
If source is having discontinuity, what does Eac3to does? Does it delete it or put empty block thr?

I have right now the same problem with one of my Bluray (Ghost Rider) and eac3t aborted the extraction of audio and video at the same point.
What can we do?

[sehgal.v7]

@boombastic
Try adding -ignorediscon, it'll solve your problem!!

[madshi]

I'm going through a manual process, extract each file and then recombine, so far so good.

To answer your question, yes that last m2ts is tiny.

I'll be happy to retry this process when you have a new eac3to available. One thing I can't do with my manual process is recombine the sup files into one so I'll hopefully get that done when you try your new version.
As I said, you can just delete (or rename) that last m2ts part and then the usual eac3to workflow should fully work. However, please note that currently Blu-Ray subtitle demuxing for seamless branching movies has a bug in it. So if you need the subtitles, you'll have to wait for the next build, anyway...

If source is having discontinuity, what does Eac3to does? Does it delete it or put empty block thr?
The discontinuity is just a counter mismatch. It doesn't have any direct effect on the video/audio data. So there's nothing eac3to has to delete or fill up. If there's a discontinuity and you used the "-ignoreDiscon" switch to force eac3to to not abort processing eac3to will try to handle the file as if it's a perfect file and simply ignores the discontinuity. If however the file is really broken, eac3to will likely detect that the audio tracks are not ok, so in that case it will abort processing, anyway.

If you just put the AVC file in mkv, that's how I'm getting duration information... and I'm using the "file info" feature in AVIMuxgui to get that. When I talk about muxing with eac3to here, I am specifically talking about just putting the AVC into mkv. All my timing information is from AVIMuxgui.

Here is the specific workflow, and what I experienced. I extracted an AVC elementary stream (with tsremux, and tsmuxer; tried both). I extracted a core DTS elementary stream with eac3to. I muxed those with mkvmerge. The audio/video was badly out of sync. I used eac3to to make an AC3 of the DTS-HD 7.1 track. I muxed again with mkvmerge. The audio/video were perfectly in sync. (A check of times of the audio tracks revealed the DTS core track to be a couple seconds shorter than the AC3 track, and that the AC3 track matched to the millisecond the duration of the video track.)

Now... as some additional info... if you extract a -core DTS file with eac3to, versus if you convert to .wavs and then make a DTS file from those .wavs with eac3to (using Surcode), you will get files of slightly different time lengths.

("How do you get time lengths?"... mux to mkv or mka and use AVIMux gui...)

And, in my limited experience, the time of the eac3to/SurCode-generated DTS file will always match the time of the video track (whether that be AVC or VC-1... can't remember a MPEG-2/DTS combo), whereas the eac3to/core DTS file will not. That seems problematic to me. I use spdifer as my DTS "decoder."
That's a much better report - thanks!

As I said in my previous post: Many DTS splitters report incorrect times for core tracks extracted from DTS-HD tracks. This is caused by core tracks only having a frame size of 2012 bytes per frame while conventional DTS tracks have 2013 bytes per frame. This slight difference causes a drift in runtime calculation - and with some DTS splitters even a drift in audio sync. If you do "eac3to core.dts" it should show you the correct runtime, though! I'm a bit surprised that mkvtoolnix creates an MKV file which is out of sync. Please run "eac3to -test" while you're online. That will tell you whether you're using the latest mkvtoolnix version or not.

Why are you using TsRemux/TsMuxer for demuxing the video track, btw? The best way to achieve good audio sync is to let eac3to do all the work. eac3to can demux video tracks just fine, too. eac3to can even directly mux a video track from m2ts/evo to MKV. So you'll save some time when you use eac3to instead of TsRemux/TsMuxer.

I have right now the same problem with one of my Bluray (Black hawk down) and eac3t aborted the extraction of audio and video at the same point.
What can we do?
You can try the "-ignoreDiscon" switch. However, chances are good (or rather bad) that your Blu-Ray rip is simply corrupted. In that case the "-ignoreDiscon" switch won't help. Your best bet is to do a clean rerip of the Blu-Ray. Use the AnyDVD HD ripping tool instead of the explorer.

[boombastic]

You can try the "-ignoreDiscon" switch. However, chances are good (or rather bad) that your Blu-Ray rip is simply corrupted. In that case the "-ignoreDiscon" switch won't help. Your best bet is to do a clean rerip of the Blu-Ray. Use the AnyDVD HD ripping tool instead of the explorer.

I ripped the disc to my hard disk with any dvd but still get the same erro. I noticed that the movie is splitted into two m2ts,one is fr thefirst hour,the second is for the last 49 minutes. Maybe this could be the problem?

[scarbrtj]

[QUOTE=boombastic;1175226]Why are you using TsRemux/TsMuxer for demuxing the video track, btw? The best way to achieve good audio sync is to let eac3to do all the work. eac3to can demux video tracks just fine, too. eac3to can even directly mux a video track from m2ts/evo to MKV. So you'll save some time when you use eac3to instead of TsRemux/TsMuxer.QUOTE]

Madshi:

If you had an .m2ts file that was AVC video and DTS-HD 7.1 track, what would your workflow be (and command line:)) to get a mkv file of the AVC video muxed with just a DTS 1536kbps core. (I thought I could only mux video track only with eac3to to mkv?)

[sehgal.v7]

@Madshi
Madshi is thr anyway to repair those discontinuities in video, except re-ripping??

[rack04]

Can someone post a sample m2ts with DTS audio for testing? I don't have a blu-ray player, therefore no blu-ray discs, and none of my HD DVD's have DTS audio. Thanks.

[rica]

Can someone post a sample m2ts with DTS audio for testing? I don't have a blu-ray player, therefore no blu-ray discs, and none of my HD DVD's have DTS audio. Thanks.

You can find one here:

http://forum.doom9.org/showthread.php?p=1174218#post1174218


_ _ _ __

[jamieo]

Hi Madshi,

Thanks for the great program - it's all I use now for BD/HD processing. :)

I have a simple request though - when encoding to dts or ac3 (from eac3 for example) with no bitrate supplied on the commandline, eac3to defaults to the largest bitrate available which will often result in a large bitrate/filesize increase with no quality improvement. Therefore, it makes sense to refine the default selection to the largest bitrate available that does not exceed the source bitrate*.

Btw, This is already the case when encoding from a higher quality to a lower quality format (LPCM -> DTS, DTS -> AC3) as the maximum bitrate available is less than the source.

Obviously I can specify the bitrate manually but as eac3to already has this info it would improve workflow by not having to check each track's bitrate and remember what options exist for that format etc..

Also, eac3to doesn't display what bitrate is being used when encoding - considering the above it would be a nice addition to prevent someone inadvertantly encoding to a file twice as big. Maybe something like 'Encoding AC3 @ 640kbit/s (with libAften)...' - a similar message for DTS could be shown before wav extraction (else too much time would have passed).

Some examples:
eac3to 768k.eac3 test.dts
Common usage as eac3 not very well supported on PC but eac3to defaults to 1536kbit/s resulting in a file twice as big. It'd be nice if eac3to would default to 768kbit/s in this case.

eac3to 192k.eac3 test.ac3
Another common usage for the 2ch commentary tracks, this results in an ac3 file @640kbit/s - most preferred selection would be to keep bitrate the same.


:thanks: Jamie

*In the examples above the same bitrates are available for each format which makes the default choice quite simple to implement. I did have examples where it wouldn't be quite so straightforward but I've since removed them as some people saw that as a cue to take the post OT.

[EPiPH0NE]

^^^

Why would you want to do AC3 -> DTS, that makes no sense???

[jamieo]

Why would you want to do AC3 -> DTS, that makes no sense???
Obviously that isn't the point of my post! If you read further you might have understood that or even noticed my note saying exactly that ac3 -> dts doesn't make sense to me!!

@everybody else,
The dts example is there for completeness as it's a possibility eac3to deals with and does not fit the generalisation I made not to exceed the source bitrate. I obviously don't suggest encoding ac3 to dts at a higher bitrate is a sensible thing to do and thought it was clear my reason for posting was to avoid that kind of thing!

My point is that better defaults could be used - esp. considering common operations such as 768k eac3 -> dts or 192k eac3 -> ac3.

[jj666]

Sorry but someone converting AC3 to DTS or AC3 to AC3 (or any other lossy to lossy format) obviously has no idea what they are doing. I don't think EAC3TO needs to cater for such things. Leave that to such things as MKV2VOB ;-p

-jj-

[nautilus7]

Why are you using TsRemux/TsMuxer for demuxing the video track, btw? The best way to achieve good audio sync is to let eac3to do all the work. eac3to can demux video tracks just fine, too. eac3to can even directly mux a video track from m2ts/evo to MKV. So you'll save some time when you use eac3to instead of TsRemux/TsMuxer.

Madshi:

If you had an .m2ts file that was AVC video and DTS-HD 7.1 track, what would your workflow be (and command line:)) to get a mkv file of the AVC video muxed with just a DTS 1536kbps core. (I thought I could only mux video track only with eac3to to mkv?)

eac3to 00001.m2ts 2: video.mkv 3: audio.dts -core
M2TS, 1 video track, 5 audio tracks, 13 subtitle tracks, 1:59:58
1: Chapters, 32 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: DTS Master Audio, English, 5.1 channels, 24 bits, 48khz, -9ms
4: DTS, Spanish, 5.1 channels, 24 bits, 768kbit/s, 48khz, -9ms
5: AC3, English, 2.0 channels, 96kbit/s, 48khz, dialnorm: -27dB, -24ms
6: AC3, English, 2.0 channels, 96kbit/s, 48khz, dialnorm: -27dB, -23ms
7: AC3, English, 2.0 channels, 96kbit/s, 48khz, dialnorm: -27dB, -23ms
8: Subtitle (PGS), English
9: Subtitle (PGS), Spanish
10: Subtitle (PGS), Spanish
[v02] Extracting video track number 2...
[a03] Extracting audio track number 3...
[a03] Extracting DTS core...
[a03] Applying DTS delay...
[v02] Muxing video to Matroska...
[a03] Creating file "audio.dts"...

To mux audio in the mkv file that eac3to makes, you need to run mkvtoolnix as a second step. eac3to can't do it automatically.

[jamieo]

Sorry but someone converting AC3 to DTS or AC3 to AC3 (or any other lossy to lossy format) obviously has no idea what they are doing. I don't think EAC3TO needs to cater for such things. Leave that to such things as MKV2VOB ;-p
Why do people have a need to find something in a post they can twist to make an argument out of that isn't even on topic to the original post? A lot of places call that trolling.

The fact that you don't believe lossy formats should be encoded between doesn't mean eac3to shouldn't support it or that people don't do it. There are a lot of people encoding from eac3 into dts and ac3 and that is what I'm most interested in. Why would they do such a thing? Because eac3 has little or no support on the PC - considering the name of the program I didn't think that would be such a hard concept to understand.

I agree encoding between ac3 and dts is pointless unless your playback device does not support dts but that is not my intention. When proposing a program modification it pays to consider all cases and that is why I included them. I'm not suggesting they be used, I'm not even suggesting that 'EAC3TO needs to cater for such things' - it already does!

[jj666]

I've converted about 75 HDDVD's to .ts for playback on the PCH and not seen many (counted on one hand) examples of 768kb/sec EAC3. In those cases, you can use the -768 switch very easily (if you wanted to convert to DTS) or it would default to 640kb/sec AC3 which is more appropriate given source bitrate. Converting a standard EAC3 1536kb/sec stream to either DTS or AC3 would result in the highest bitrate possible by default as you already mentioned, which again would be appropriate.

If you are using the EAC3TO frontend it only supports one audio stream, if you are using the command line for multiple streams, it's no additional hassle to add multiple switches.

I still don't see any reason why EAC3TO should have hardcoded thinking regarding output bitrate when it has such a broad format of options for conversion...

-jj-

[jamieo]

I still don't see any reason why EAC3TO should have hardcoded thinking regarding output bitrate when it has such a broad format of options for conversion...
I'm not suggesting it should - Quite the opposite as I'm asking that the hard coded defaults that already exist be derived from the source bitrate to prevent the default being something that nobody would ever seriously want. Obviously, switches would still override them as they do now.

My own reason for this is to save time typing out switches and evaluating which track has which bitrate etc. when I already know I want the largest bitrate that doesn't exceed the source bitrate. I think it should make sense to most as a default.

I've also seen a few HD episodes which have 2ch AC3 @640kbit/s - it seems obvious to me that someone has left the defaults alone in whatever program they were using and didn't really intend such a high bitrate. While not my primary concern, my suggestion should also avoid such mistakes.

I'm not sure you get what I'm asking so let me clarify that my suggestion wouldn't change anything that effects your use of eac3to - only the defaults applied for those that do lossy to lossy and as such (by your own words) 'obviously has no idea what they are doing' so I'd think such improvements would be welcome.

Btw, I'm not interested in going over this any more for such a simple suggestion. My post was for madshi and I'm only really interested in his thoughts on this.

[rica]

Btw, I'm not interested in going over this any more for such a simple suggestion. My post was for madshi and I'm only really interested in his thoughts on this.

Yes, this was your point.

[Snowknight26]

I guess you have to understand how audio compression works. Say that full bitrate AC3 (640kbps) is transparent to the source, no matter what the source is. So if you have a 6916kbps PCM stream thats converted to AC3, its audibly transparent. Same applies for a 192kbps AC3 stream. If you transcode that stream to AC3, in order for it to the new one to be transparent, it would have to be full bitrate - 640kbps.
Now, lest try something else. Assume that DTS is the same way with its full bitrate (1536kbps) streams. What if you were to reencode a 768kbps E-AC3 stream to DTS but you wanted to make it audibly transparent? Use full bitrate DTS. Therefore, If you want to do 768kbps E-AC3 to 768kbps, you're losing lots of data.

I guess the point you have to see is that you can't compare bitrates from different audio formats that easily.




Now that thats out of the way, I found it peculiar that I can't demux subtitles from a VOB. Unless I'm out of the loop on how to do that, is there any plan to add that feature?

Also:
eac3to.exe VTS_01_1.VOB+VTS_01_2.VOB+VTS_01_3.VOB 4: animusic.ac3

VOB, 1 video track, 3 audio tracks, 1 subtitle track, 0:32:53
1: Joined VOB file
2: MPEG2, 480i60 /1.001 (4:3)
3: AC3, 2.0 channels, 256kbit/s, 48khz, dialnorm: -27dB, 16ms
4: AC3, 5.1 channels, 448kbit/s, 48khz, dialnorm: -27dB, 16ms
5: AC3, 2.0 channels, 192kbit/s, 48khz, dialnorm: -27dB, 16ms
6: Subtitle
[a03] The stream doesn't seem to contain any valid (E-)AC3 frames.
Aborted at file position 2204442624.
Total size of the 3 files is, funny enough, 2204442624. It detects that it has an AC3 stream in it but it says it doesn't have any valid AC3 frames. Wonder how it detected that in the first place then. Sample VOB (http://www.stfcc.org/misc/animusic.clip.vob).

[deacon crusher]

You called it.

First try had audio sync issues.

I then rebuilt the final mkv without the first (studio intro) and last (incredibly short) m2ts files and I've got a great mkv with chineese and english audio in it with no sync issues.

I'll rerip the subtitles and add them back in when the next version is available.

And now that I have a disk that has this problem also happy to test the next version to see if this issue is dealt with.

Also, for seamless branching disks do I understand correctly that the best way will always be to rip each m2ts in the playlist using eac3to, then combine video files into an mkv with eac3to, then combine audio files into one audio file with eac3to, mux audio file into mkv with mkvtoolnix? And do the same thing with subtitles if/when those are needed? Any way to add/get chapter info for disk in this instance?

Thanks

As I said, you can just delete (or rename) that last m2ts part and then the usual eac3to workflow should fully work. However, please note that currently Blu-Ray subtitle demuxing for seamless branching movies has a bug in it. So if you need the subtitles, you'll have to wait for the next build, anyway...


The discontinuity is just a counter mismatch. It doesn't have any direct effect on the video/audio data. So there's nothing eac3to has to delete or fill up. If there's a discontinuity and you used the "-ignoreDiscon" switch to force eac3to to not abort processing eac3to will try to handle the file as if it's a perfect file and simply ignores the discontinuity. If however the file is really broken, eac3to will likely detect that the audio tracks are not ok, so in that case it will abort processing, anyway.


That's a much better report - thanks!

As I said in my previous post: Many DTS splitters report incorrect times for core tracks extracted from DTS-HD tracks. This is caused by core tracks only having a frame size of 2012 bytes per frame while conventional DTS tracks have 2013 bytes per frame. This slight difference causes a drift in runtime calculation - and with some DTS splitters even a drift in audio sync. If you do "eac3to core.dts" it should show you the correct runtime, though! I'm a bit surprised that mkvtoolnix creates an MKV file which is out of sync. Please run "eac3to -test" while you're online. That will tell you whether you're using the latest mkvtoolnix version or not.

Why are you using TsRemux/TsMuxer for demuxing the video track, btw? The best way to achieve good audio sync is to let eac3to do all the work. eac3to can demux video tracks just fine, too. eac3to can even directly mux a video track from m2ts/evo to MKV. So you'll save some time when you use eac3to instead of TsRemux/TsMuxer.


You can try the "-ignoreDiscon" switch. However, chances are good (or rather bad) that your Blu-Ray rip is simply corrupted. In that case the "-ignoreDiscon" switch won't help. Your best bet is to do a clean rerip of the Blu-Ray. Use the AnyDVD HD ripping tool instead of the explorer.

[madshi]

Madshi is thr anyway to repair those discontinuities in video, except re-ripping??
As I said, discontinuities are just a counter mismatch. It doesn't necessarily need repairing, if only the counter mismatch while the data is ok. But most often if the counters mismatch, the data is corrupted, too. And if the data is corrupted, there's no way to correct that other than to rerip the movie.

I have a simple request though - when encoding to dts or ac3 (from eac3 for example) with no bitrate supplied on the commandline, eac3to defaults to the largest bitrate available which will often result in a large bitrate/filesize increase with no quality improvement. Therefore, it makes sense to refine the default selection to the largest bitrate available that does not exceed the source bitrate*.
I understand your request, but I don't agree with it. The reason is this: We're talking about *lossy* encoding here. So if you decode a lossy audio track and reencode it again with a lossy codec you are automatically losing audio quality. That means if you decode e.g. a 768kbps E-AC3 track and reencode it in 768kbps DTS or AC3 you are losing audio quality. You're losing audio quality even if you reencode to a higher bitrate! That's the way lossy audio codecs work: Every new encoding loses *some* audio quality. Using the same bitrate as the lossily compressed source has is therefore not the way to go if you want to avoid having too much audio quality loss. My personal preference is best possible audio quality. That's why eac3to defaults to max quality for most options. Yes, that means that an audio transcode increases the file size of the audio track. But at least we can do that without fearing that too much audio quality is lost.

I'm aware that some people find the eac3to's defaults too high. But that's why there are options to lower them. You will never find a default everybody agrees with. Somebody will always have a different opinion. So I chose the defaults which I personally prefer and I won't change them unless somebody finds a good argument to convince me or unless the majority of eac3to users agree on how the defaults should be.

Also, eac3to doesn't display what bitrate is being used when encoding - considering the above it would be a nice addition to prevent someone inadvertantly encoding to a file twice as big. Maybe something like 'Encoding AC3 @ 640kbit/s (with libAften)...' - a similar message for DTS could be shown before wav extraction (else too much time would have passed).
Yes, that makes sense. Will add that to my to do list.

Also, for seamless branching disks do I understand correctly that the best way will always be to rip each m2ts in the playlist using eac3to
*NO*. The way to go is never to handle each m2ts part separately. You should always let eac3to handle them all at once. Either by using "part1.m2ts+part2.m2ts+..." or by letting eac3to parse the playlists. It just so happens that some movies seem to have a very small m2ts part at the end which has different tracks inside compared to the other m2ts parts. That confuses eac3to. That's why I suggested to delete/rename that last small m2ts part. eac3to will automatically ignore such confusing m2ts parts in the next build...

[scarbrtj]

eac3to 00001.m2ts 2: video.mkv 3: audio.dts -core
M2TS, 1 video track, 5 audio tracks, 13 subtitle tracks, 1:59:58
1: Chapters, 32 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: DTS Master Audio, English, 5.1 channels, 24 bits, 48khz, -9ms
4: DTS, Spanish, 5.1 channels, 24 bits, 768kbit/s, 48khz, -9ms
5: AC3, English, 2.0 channels, 96kbit/s, 48khz, dialnorm: -27dB, -24ms
6: AC3, English, 2.0 channels, 96kbit/s, 48khz, dialnorm: -27dB, -23ms
7: AC3, English, 2.0 channels, 96kbit/s, 48khz, dialnorm: -27dB, -23ms
8: Subtitle (PGS), English
9: Subtitle (PGS), Spanish
10: Subtitle (PGS), Spanish
[v02] Extracting video track number 2...
[a03] Extracting audio track number 3...
[a03] Extracting DTS core...
[a03] Applying DTS delay...
[v02] Muxing video to Matroska...
[a03] Creating file "audio.dts"...

To mux audio in the mkv file that eac3to makes, you need to run mkvtoolnix as a second step. eac3to can't do it automatically.

I am going to do it *exactly* this way then report back :fingers crossed: :thanks:

[jamieo]

if you decode a lossy audio track and reencode it again with a lossy codec you are automatically losing audio quality. That means if you decode e.g. a 768kbps E-AC3 track and reencode it in 768kbps DTS or AC3 you are losing audio quality. You're losing audio quality even if you reencode to a higher bitrate! That's the way lossy audio codecs work: Every new encoding loses *some* audio quality.
I already understand and completely agree with that. In fact it's the exact reason I made the request and didn't think it would be a big deal. Ideally we'd keep all the tracks as they are and they would play on anything we like - however, they don't and that is why we use eac3to.

My personal preference is best possible audio quality. That's why eac3to defaults to max quality for most options.
Given what you just said about quality loss, do you really encode (or think it worth encoding) lossy tracks to files that will be two or three times as big as the source? I can't imagine there is a significant quality improvement (audible or otherwise) encoding a 768kbit/s eac3 track to DTS at 1536kbit/s rather than 768kbit/s but the file size increase is very significant. Even worse for commentary tracks in EAC3 when the default is 640kbit/s for AC3.

Anyway, the whole point of this was because I have written a menu based wrapper script for eac3to and it was originally my intention to make it so default bitrates were determined according to source if no explicit bitrate is given. However, I thought it better suited as an eac3to suggestion so others benefited. Not only is there some irony in that thought (considering the reaction my suggestion got) but I'm now going to do that anyway and will have it set up in much less time than it took me to write these posts. I guess no good deed goes unpunished! :)

Anyway, it's obviously your right to program eac3to however you like so I won't discuss it further.

Yes, that makes sense. Will add that to my to do list.
Cheers, that should at least make it clear that a high bitrate is being used.

Thanks for a great program.

[madshi]

I can't imagine there is a significant quality improvement (audible or otherwise) encoding a 768kbit/s eac3 track to DTS at 1536kbit/s rather than 768kbit/s but the file size increase is very significant.
You're trying to see a connection between source and target bitrate which IMHO isn't there. The source bitrate tells us how much loss there was in the lossy encoding done by the studio. The target bitrate defines how much loss we want to add on top of that ourselves. These 2 losses don't relate to each other, they simply add up (loss 1 + loss 2). Now what you're saying sounds to me like: If the "loss 1" is big then you want eac3to to make "loss 2" equally big. That doesn't make much sense to me.

[Snowknight26]

http://www.stfcc.org/misc/animusic.clip.vob

eac3to v2.57
command line: eac3to.exe animusic.clip.vob 5: animusic.sup
------------------------------------------------------------------------------
VOB, 1 video track, 3 audio tracks, 1 subtitle track, 0:00:08
1: MPEG2, 480i60 /1.001 (4:3)
2: AC3, 2.0 channels, 256kbit/s, 48khz, dialnorm: -27dB, 16ms
3: AC3, 5.1 channels, 448kbit/s, 48khz, dialnorm: -27dB, 16ms
4: AC3, 2.0 channels, 192kbit/s, 48khz, dialnorm: -27dB, 16ms
5: Subtitle
eac3to processing took 1 second.
Done.

No file is produced.

[madshi]

http://www.stfcc.org/misc/animusic.clip.vob

No file is produced.
I can only guess that there isn't any data in the subtitle track.

Edit: Something about that vob file is strange, though. eac3to cannot demux video/audio tracks for whatever reason. Will look into that. But the subtitle track seems to be really empty. E.g. EvoDemux doesn't even list it.

[deacon crusher]

Oh that's great news, I thought I'd read on the forum that if you let EAC3to merge the pieces on a seamless branching disk that you would/could end up with audio sync issues.

Must have misunderstood something I read.

Thanks


*NO*. The way to go is never to handle each m2ts part separately. You should always let eac3to handle them all at once. Either by using "part1.m2ts+part2.m2ts+..." or by letting eac3to parse the playlists. It just so happens that some movies seem to have a very small m2ts part at the end which has different tracks inside compared to the other m2ts parts. That confuses eac3to. That's why I suggested to delete/rename that last small m2ts part. eac3to will automatically ignore such confusing m2ts parts in the next build...

[madshi]

Oh that's great news, I thought I'd read on the forum that if you let EAC3to merge the pieces on a seamless branching disk that you would/could end up with audio sync issues.

Must have misunderstood something I read.
You got it exactly the wrong way. Actually letting eac3to merge the seamless branching parts *solves* any audio sync issues. If you handle the parts separately, you'll get into trouble because the audio data overlaps slightly, so audio sync will slowly drift out of sync over the course of the movie. eac3to will detect the audio overlaps and correct them for you if you let eac3to handle the merging.

[florinandrei]

So what happens when eac3to detects that the audio track is muxed with a delay? Does it insert silence at the beginning of the extracted audio track so as to preserve A/V sync?

[sehgal.v7]

@florinandrei
Yeap.. It automatically adds delay.

[a03] Applying DTS delay...

[rickardk]

Sorry for not posting my new results with The Game Plan sooner.

It must be some kind of mastering error. I tested every m2ts file in the playlist and found the problem(s).

Sorry for taking your time with this problem.