eac3to - audio conversion tool

[madshi]

So, I'll get better quality on padded sources if I first demux/convert to .wav? That way eac3to can work out if its padded or true 24bit. If its padded it'll do a second pass and remove the padding and if its 24bit it will stay as 24bit and I can then run it through eac3to again with -down16?
Yeah, for max quality that would be the best approach.

[mrr19121970]

Would it be much work to automatically create a second file containing only the forced captions while extracting this stream?


I guess it would be possible, but I don't know how difficult it would be. I'll put it on my to do list.


Whilst eac3to is back in focus, I'm wondering if you'd had time to think about extracting forced subs into an extra file?

[madshi]

Whilst eac3to is back in focus, I'm wondering if you'd had time to think about extracting forced subs into an extra file?
It is on my to do list - like so many other things I'd like to add to eac3to. I'm currently lacking time, though. And the time I can find for HTPC development mostly go into madVR at this point, since madVR is still a work in progress, while eac3to is pretty stable. There probably will come a time when I come back to eac3to with more development resources, but it's not here yet right now. (3D was important and easy to add.)

[dansrfe]

So are there any decoders which decode non 24-bit padded 16-bit DTS properly and account for the variations in frequency domain representation when the PCM audio is recreated during decoding? Does ffdshow audio decoder properly do that with the 24-bit padding? Also I've always been curious to know why are there different outputs for the different bit integers. I have checked only 32 bit floating point because I assumed it was the "best" option and gives the decoder lots of "room" for whatever it needs to do though it might unnecessarily raise cpu usage since the decoding actually only needs 24-bit for 16-bit Digital Dolby or DTS audio.

[madshi]

So are there any decoders which decode non 24-bit padded 16-bit DTS properly and account for the variations in frequency domain representation when the PCM audio is recreated during decoding?
Huh? You're confusing me.

Standard DTS is never padded 16bit. It's floating point.

DTS-MA is usually also never padded 16bit. It's either 16bit, and then the decoder outputs 16bit. Or it's 24bit and then the decoder outputs 24bit.

The only situation where 16bit -> 24bit padding usually occurs is with TrueHD/MLP tracks. I've seen tons of DTS-MA tracks and their bitdepth information is usually correct. I've only ever seen one single DTS-MA track which was flagged as 24bit, but only contained 16bit data, while I've seen hundreds of DTS-MA tracks which were flagged correctly.

[dansrfe]

Sorry I should have been more clear in my wording. What I meant to say was that is there any decoder which will correctly decode DTS audio encoded from 16-bit and which has not been flagged as 24-bit?

[madshi]

That still doesn't make any sense. Are you talking about standard DTS or DTS-MA?

[dansrfe]

Standard DTS. The link in some posts above said that when standard dts is converted to PCM via decoding it is 8 bits more therefore some decoders need the 24-bit padding in order to have all the bits that's why I was wondering if there are any decoders that can play without the padding and still anticipate 8 bits more when decoding.

[madshi]

I don't know for sure which decoders are outputting what, if eac3to doesn't patch the bitdepth to 24bit. ArcSoft outputs 16bit without the patching, I think. To which bitdepth libav/ffmpeg decodes, depends on the libav/ffmpeg version and the decoder/media player which uses it. If you decode by using eac3to, you will always get full bitdepth.

[TinTime]

madshi

A bit more info - I've been looking further into the problem I reported with reducing the bitdepth of 24 bit audio.

It seems to be near peak values that don't necessarily have their depth reduced. Presumably dithering means that a value can be rounded up or down. However near the peak I suppose the value should always be rounded down - ie truncated.

For example the centre channel in the test file I posted contains the following sequence of samples (as wav):

24 bit in 20 bit out
EC 65 77 F0 65 77
FC FF 7F FF FF 7F
FE FF 7F FF FF 7F
FD FF 7F F0 FF 7F
51 E8 5C 50 E8 5C

I reran my test file through eac3to using...
eac3to.exe "test1 24.flac" "test1 20.flac" -1dB -down20
...and it worked correctly. In fact perhaps this is the correct approach. The bit depth reduction in this case would introduce clipping otherwise.

[Nando1970]

It is on my to do list - like so many other things I'd like to add to eac3to. I'm currently lacking time, though.

madshi would you consider to open-source eac3to?
There might be people out there willing to contribute development time.

Thank you anyway for your great tool

ciao -- Nando

[madshi]

A bit more info - I've been looking further into the problem I reported with reducing the bitdepth of 24 bit audio.
Thanks, that's helpful!

madshi would you consider to open-source eac3to?
No.

[madshi]

eac3to v3.20 released

http://madshi.net/eac3to.zip

* fixed 3D demuxing (argh)
Stupid bug, was demuxing the left eye stream for both left and right eye.

[Thunderbolt8]

regarding 3d remuxing, wouldnt it be better to have both streams output in seperate .mkv files instead of the raw .h264 streams? i remember you said its better to remux to .mkv instead of demuxing the stream, because then some parameters or other stuff in the chain could get lost or something like that.

[Frank K Abbott]

I'm curious to know, are there even any 3D Blu Ray's in the market?

[setarip_old]

@Frank K Abbott

Apparently so:

http://forum.doom9.org/showthread.php?p=1394311#post1394311

[madshi]

regarding 3d remuxing, wouldnt it be better to have both streams output in seperate .mkv files instead of the raw .h264 streams?
Haali's Matroska Muxer doesn't seem to like the right eye stream, so that's not possible.

i remember you said its better to remux to .mkv instead of demuxing the stream, because then some parameters or other stuff in the chain could get lost or something like that.
Well, muxing to a container is better only if there are overlaps or gaps in the video stream. I've never seen that with Blu-Ray yet. It might happen for broadcasts, especially when there are recording glitches, though.

[volence]

I'm sorry if there had been similar question before, since the thread is too long for me to go through.
I want to know can eac3to convert 6.1 and 7.1 ch TrueHD audio to aac? I think I'm using the last free version of Nero AAC, and it tells me Nero doesn't support 6.1ch or higher. Is there any way to encode 6.1 AAC with eac3to (using freeware)?

[ramicio]

would a numerical progress indicator be feasible? i have my windows larger with a different font than default so i have no idea how far along the file is.

[Momber]

It's prollly just cosmetic, but why does eac3to insist there is a newer version of Haali available, when there really isn't?

http://pickhost.eu/images/0003/6578/eac3to.gif

[Snowknight26]

Because that's how the website (http://haali.su/mkv/) shows it.

[Momber]

But that's where I have it from....

[Snowknight26]

So what are you confused about? File date say one thing, website says another.

[stasi]

I'm sorry if there had been similar question before, since the thread is too long for me to go through.
I want to know can eac3to convert 6.1 and 7.1 ch TrueHD audio to aac? I think I'm using the last free version of Nero AAC, and it tells me Nero doesn't support 6.1ch or higher. Is there any way to encode 6.1 AAC with eac3to (using freeware)?

If you have more than 6 channels, you have to encode to FLAC. Nero AAC is limited to 6 channels.

[tormento]

There is a nice Flac CUDA compression implementation here:

http://cuetools.net/doku.php/flacuda

and source too.

Do you think could be feasible to implement it in the next version? ;)

[komisar]

FlaCuda:
"Bits per sample must be 16."
ChannelCount must be 2.

[nibus]

If you have more than 6 channels, you have to encode to FLAC. Nero AAC is limited to 6 channels.

I thought AAC supported 7.1 as long as you use the Arcsoft decoder. It doesn't support 6.1 so it doubles the last track.

[Snowknight26]

AAC has nothing to do with ArcSoft's decoder.

[Laurent]

Hi

When handling HD-DVD, I discovered that the chapter timestamps are wrong. On the first chapters, the timing is ok or almost ok, and then the difference grows up with the next chapters, leading to several seconds on the last chapters. The chapter jump leads to a position before the real position.
Could it be a bug in eac3to ?
Could it be something relative to pulldown removal ? (29.976 to 23.976)
Is there a solution to correct that ?

PS: I have to mention that I notice this problem after producing AVCHD discs with multiAVCHD, so the problem could be either with eac3to or with multiAVCHD. But as I already noticed the same thing with MKV production, I think it could be more in relation with eac3to actions.

[TinTime]

Hi

When handling HD-DVD, I discovered that the chapter timestamps are wrong. On the first chapters, the timing is ok or almost ok, and then the difference grows up with the next chapters, leading to several seconds on the last chapters. The chapter jump leads to a position before the real position.
Could it be a bug in eac3to ?

Do the timestamps in the chapter text file produced by eac3to match the timestamps in the HD DVD xml file? If so then the problem isn't with eac3to.

[Laurent]

Do the timestamps in the chapter text file produced by eac3to match the timestamps in the HD DVD xml file? If so then the problem isn't with eac3to.

I can't verify it immediately but I will do it later. I was not aware of this XML file.

The question is: should the pulldown removal (done by eac3to) have an impact on chapter timestamps ? I believe it sould not ?

I hade done a fast computation, I don't think the problem could be a mistake between 29.970 and 23.976, but it could be between 23.976 and 24.000. Such mistake leads to 7 seconds after 2 hours.

[Laurent]

Do the timestamps in the chapter text file produced by eac3to match the timestamps in the HD DVD xml file? If so then the problem isn't with eac3to.

Which XML file are you talking about ? I just loaded a HD-DVD and in the HVDVD_TS directory, the only file extensions are BUP, EVO, MAP and VTI.

[TinTime]

I forget what they're called or where they are (sorry) but have a look in other directories on the disk. When you look at it there will be all kinds of track info, including chapters.

[Laurent]

How are extracted chapter timestamps from HD-DVD discs ? I mean, are they computed or are they just read somewhere on the disc ?

I checked with a Blu-Ray disc and there is no problem with the chapter timestamps.
They are wrong only when handling HD-DVD discs.

I would be curious to see if it changes something if I disable "pulldown removal". Is there an eac3to option to disable pulldown removal when video is interlaced at 29.97 Hz ?

[Laurent]

I forget what they're called or where they are (sorry) but have a look in other directories on the disk. When you look at it there will be all kinds of track info, including chapters.

Ok, I found the file, its name is VPLST000.XPL. Here is an extract of the file:
<ChapterList>
<Chapter id="mainMovie_ch1" titleTimeBegin="00:00:00:00" />
<Chapter id="mainMovie_ch2" titleTimeBegin="00:05:21:25" />
<Chapter id="mainMovie_ch3" titleTimeBegin="00:12:36:02" />
<Chapter id="mainMovie_ch4" titleTimeBegin="00:22:08:15" />
<Chapter id="mainMovie_ch5" titleTimeBegin="00:32:29:25" />
<Chapter id="mainMovie_ch6" titleTimeBegin="00:38:52:32" />
<Chapter id="mainMovie_ch7" titleTimeBegin="00:44:50:17" />
<Chapter id="mainMovie_ch8" titleTimeBegin="00:52:58:25" />
<Chapter id="mainMovie_ch9" titleTimeBegin="01:02:30:57" />
<Chapter id="mainMovie_ch10" titleTimeBegin="01:15:02:02" />
<Chapter id="mainMovie_ch11" titleTimeBegin="01:24:36:07" />
<Chapter id="mainMovie_ch12" titleTimeBegin="01:36:12:12" />
<Chapter id="mainMovie_ch13" titleTimeBegin="01:41:26:15" />
<Chapter id="mainMovie_ch14" titleTimeBegin="01:49:51:27" />
<Chapter id="mainMovie_ch15" titleTimeBegin="02:01:21:02" />
<Chapter id="mainMovie_ch16" titleTimeBegin="02:09:47:07" />
<Chapter id="mainMovie_ch17" titleTimeBegin="02:19:03:35" />
<Chapter id="mainMovie_ch18" titleTimeBegin="02:24:09:35" />
<Chapter id="mainMovie_ch19" titleTimeBegin="02:34:18:42" />
<Chapter id="mainMovie_ch20" titleTimeBegin="02:39:13:05" />
</ChapterList>
And here is the file Chapters_2.txt produced by eac3to:
CHAPTER01=00:00:00.000
CHAPTER01NAME=
CHAPTER02=00:05:21.416
CHAPTER02NAME=
CHAPTER03=00:12:36.033
CHAPTER03NAME=
CHAPTER04=00:22:08.250
CHAPTER04NAME=
CHAPTER05=00:32:29.416
CHAPTER05NAME=
CHAPTER06=00:38:52.533
CHAPTER06NAME=
CHAPTER07=00:44:50.283
CHAPTER07NAME=
CHAPTER08=00:52:58.416
CHAPTER08NAME=
CHAPTER09=01:02:30.950
CHAPTER09NAME=
CHAPTER10=01:15:02.033
CHAPTER10NAME=
CHAPTER11=01:24:36.116
CHAPTER11NAME=
CHAPTER12=01:36:12.200
CHAPTER12NAME=
CHAPTER13=01:41:26.250
CHAPTER13NAME=
CHAPTER14=01:49:51.450
CHAPTER14NAME=
CHAPTER15=02:01:21.033
CHAPTER15NAME=
CHAPTER16=02:09:47.116
CHAPTER16NAME=
CHAPTER17=02:19:03.583
CHAPTER17NAME=
CHAPTER18=02:24:09.583
CHAPTER18NAME=
CHAPTER19=02:34:18.700
CHAPTER19NAME=
CHAPTER20=02:39:13.083
CHAPTER20NAME=
So the timestamps are not eactly the same but the differences are not big.
I will create an AVCHD with this one and check with the PS3 how good are the chapter marks compared to the HD-DVD player.

[Laurent]

Is there an eac3to option to disable pulldown removal when video is interlaced at 29.97 Hz ?

Ok, found, this iis "-keepPulldown".

[SomeJoe]

Laurent,

When dealing with NTSC-derived frame rates (29.97, 23.976), the timecodes on HD-DVD and BD are actually non-drop-frame timecodes. But most of the multiplexing programs out there (TSMuxer, MKVMerge) treat them as real time. This leads to the 3.5 seconds per hour offset.

If you convert the timecodes from non-drop-frame to drop-frame, the chapters points will be exact.

This doesn't have anything to do with pulldown removal. The root of the problem is that the OGG chapter format doesn't have any way to specify NDF or DF timecodes, it's up to the program being used to interpret them correctly.

[Laurent]

Laurent,

When dealing with NTSC-derived frame rates (29.97, 23.976), the timecodes on HD-DVD and BD are actually non-drop-frame timecodes. But most of the multiplexing programs out there (TSMuxer, MKVMerge) treat them as real time. This leads to the 3.5 seconds per hour offset.

If you convert the timecodes from non-drop-frame to drop-frame, the chapters points will be exact.

Thank you for the explanation.
Can you tell me what coefficient should I apply to each timestamp to get the correct value ?

This doesn't have anything to do with pulldown removal. The root of the problem is that the OGG chapter format doesn't have any way to specify NDF or DF timecodes, it's up to the program being used to interpret them correctly.

If pulldown removal is not concerned, I don't really understand what you call drop frames ?

[mczuzlak]

I know I can encode to ac3 from any format with eac3to but is it possible to encode an ac3 file from multiple wavs ? (each one is a channel, like left and right)

[nurbs]

No, you need to merge them to a multi channel wav first. Software that can do that has been repeatedly mentioned in this thread, but I can't remember application names, sorry.

[Thunderbolt8]

wavewizard can combine multiple wav files into a single one (or another format)

[Thunderbolt8]

someone said that a dts-hd ma --> flac file created with 3.20 was a tiny bit different compared to when it was created with 3.18, can anyone confirm this?

[mczuzlak]

No, you need to merge them to a multi channel wav first. Software that can do that has been repeatedly mentioned in this thread, but I can't remember application names, sorry.

wavewizard can combine multiple wav files into a single one (or another format)

thx guys

[krohm]

im sure this has been posted before but the search function didnt yield me much of a result. i want to transcode various dts formats from bluray into a lossless format that will load in powerdirector. ive read the eac3to howto guide but it got a little confusing and only allowed me to be able to convert dts to ac3.

i think afterwards i use surcode or something to create a dts wav that can load to powerdirector... im not sure..

ive been advised i need to convert the dts file into multiple wav's then individually load the wav's into the editor. i need eac3to for this but am new to the program and dont know how to use the command line. need some command line assistance as it is a real sticking point for me atm as cant edit any bluray clips with lossless sound. i dont want to use the ac3 and wanted to know if someone could help me out with the command line to convert the dts to wav's...

[djloewen]

I've got three things to add to this thread. The first appears to be a bug in the program. The second is apparently a problem that not everyone is having, but certainly I am. The third is a feature request.

1.) The bug:
On the Blu-Ray "Batman: Gotham Knight" there are four bonus episodes of "Batman: The Anmated Series". These are reported by eac3to as "480p24/1.001 (3:2) with pulldown flags", and the demuxed VC1 stream is 23.976fps. This is incorrect, and results in the video being played back at the wrong speed. DGindexNV correctly reports that it is 29.970, no pulldown, no interlacing.

100mb sample here:
http://www.megaupload.com/?d=MKOFDA0W

2.) The problem:
I reported this initially in a separate thread, and in fact it's a little more widespread than I had thought. When I run eac3to on the Blu-Ray disc for "The Bad Lieutenant: Port of Call - New Orleans", it lists 3 titles. So:

eac3to E:\
shows three titles, each with a number of streams.

eac3to E:\ 1)
does nothing. it draws a bunch of "-" characters as it scans the disc, then it returns me to the prompt.

eac3to E:\BDMV\PLAYLIST\00000.mpls
lists one title with a number of streams.

E:\BDMV\PLAYLIST\00000.mpls 1)
again, does nothing.

I am able to open/rip the m2ts files directly, bypassing the playlist files. However, there are two m2ts files in this case and I want eac3to to demux them as one file.

Since first discovering the problem with that one disc, I've encountered the exact same problem with the ~5min short film extras on two separate Pixar discs. In one case it's a single m2ts file (and so I've just demuxed that), for the others it's two or three. But in all cases, the playlist files just don't show the streams. Any help would be greatly appreciated.

3.) The feature request:
I would personally find it very useful to be able to choose not a full stream/playlist, but just a range of chapters, and then demux the audio/video/subs for just that selection.

[SomeJoe]

Thank you for the explanation.
Can you tell me what coefficient should I apply to each timestamp to get the correct value ?

If pulldown removal is not concerned, I don't really understand what you call drop frames ?


Pulldown flags are indicators within a 23.976 fps video stream that tell the playback device to repeat certain fields in a 3:2 pattern. This causes the playback to be 29.97 fps. Telling eac3to.exe -keepPulldown will cause the video stream to be extracted with the pulldown flags intact. Normally, eac3to removes them. But this doesn't have anything to do with your problem.

Drop-frame (DF) and Non-drop-frame (NDF) timecodes are labels that are attached to each frame of a 29.97 fps video stream. I emphasize that -- they are labels that uniquely identify each frame. Despite the name, no frames are dropped from the video stream, either in the storage media or during playback.

A DF label is of the form hh;mm;ss;ff (Note semicolons).

A NDF label is of the form hh:mm:ss:ff (Note colons).

There is a one-to-one-to-one correspondence between a DF timecode label, an NDF timecode label, and a frame number.

To convert from an NDF timecode label to a DF timecode label (or vice versa), you convert the NDF timecode label to a frame number, and then convert the frame number to a DF timecode label.

The difference between an NDF label and a DF label is as follows:

NDF labels use a very simple counting mechanism. They count 0-29 on frames, 0-59 on seconds, 0-59 on minutes, and 0-any number for hours. There is no compensation for the fact that this counting mechanism assumes that there are exactly 30 frames per second, but there are not. NTSC frame rates do not play back at 30.000, they play back at 29.97. Thus, NDF timecode labels will slowly depart from real wall-clock time.

DF timecode labels use a modified counting mechanism that compensates for the fact that the playback rate is not 30.000, but is instead 29.97. In DF timecodes, frames count 0-29, seconds count 0-59, minutes count 0-59, and hours count 0-any number just like NDF, BUT:

- Frame numbers ;00 and ;01 are skipped on every 1-minute boundary, except for 10-minute boundaries.

Thus, the following:


DF Timecode NDF Timecode Frame #
00;00;59;28 00:00:59:28 1798
00;00;59;29 00:00:59:29 1799
00;01;00;02 00:01:00:00 1800
00;01;00;03 00:01:00:01 1801
00;01;00;04 00:01:00:02 1802


At the 1 hour (wall-clock time) point in the video, the DF timecode will be 1;00;00;00, whereas the NDF timecode will be 00:59:56:13.

The chapter points on the disc are NDF. But the OGG chapter format specifies chapter points in terms of wall-clock time, not timecode. To convert the NDF timecodes on the disc to wall-clock time:

Frame number = (((hh * 60) + mm) * 60 + ss) * 30 + ff

Wall-clock time (seconds) = Frame number / (30000/1001)

Example:

NDF timecode = 01:35:23:17

Since this is about an hour and half into the film, and the offset is approximately 3.5 seconds per hour, we would expect this to convert to a wall-clock time that's about 5.5 seconds later than this timecode, somewhere in the 1:35:29.xxx area.

Frame number = (((1 * 60) + 35) * 60 + 23) * 30 + 17 = 171707.

Wall-clock time = 171707 / (30000/1001) = 5729.290 seconds.

5729.290 Mod 60 = 29.29
5700 Mod 3600 / 60 = 35
3600 / 3600 = 1

Wall-clock time = 01:35:29.290


Note that DF timecodes and wall-clock time are not exactly the same. DF timecodes use frame numbers, wall-clock time uses fractional seconds.

Ideally, eac3to should produce an OGG chapter format file with this conversion already done, since the OGG chapter format file is supposed to use wall-clock time, not an NDF timecode expressed in fractional seconds.

Note that NDF and DF timecodes are only valid for 29.97 fps streams. There is no such thing as a DF or NDF timecode for a 23.976 stream, and I think there is where the problem is coming in. The timecodes on the disc for HD-DVD and BD shouldn't be NDF in the first place, as that isn't valid for a 23.976 stream.

[TinTime]

I am able to open/rip the m2ts files directly, bypassing the playlist files. However, there are two m2ts files in this case and I want eac3to to demux them as one file.

I can't help with your other problems but you can join files easily enough with eac3to.

eg.
eac3to.exe 00000.m2ts+00001.m2ts+00002.m2ts 1: video.h264 2: audio.ac3 etc.

[djloewen]

I can't help with your other problems but you can join files easily enough with eac3to.


Is there any downside to using this method as opposed to the playlist? For example, might there end up being audio or subtitle sync problems? Or does the playlist ever specify only using part of a stream?

[Atak_Snajpera]

I remember that In order to have working PCM audio in AVCHD/BluRay structure we had to first:
1) decompress DTS-MA/TrueHD/LPCM audio to .wav
2) convert decompressed .wav to .w64
3) import .w64 in tsmuxer

Is this still necessary ?

[TinTime]

Is there any downside to using this method as opposed to the playlist? For example, might there end up being audio or subtitle sync problems? Or does the playlist ever specify only using part of a stream?

You don't get chapters or (I think) the language codes for audio / subs. There shouldn't be any sync problems though.