[madshi]

Originally Posted by 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.

Sorry, but 99% of the people seem to be happy with the progress bar.

Originally Posted by 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?

I'm not aware of any change in eac3to that would result in this behaviour.

Originally Posted by 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.

I don't know powerdirector. Tell us which format powerdirector needs and then maybe we can give you the eac3to command you need to use.

Originally Posted by djloewen

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

eac3to is not handling VC-1 interlaced content correctly. I'm aware of that. It's on my (very long) to do list.

Originally Posted by djloewen

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.

From what I remember, other people didn't have this problem, or did they? Can anybody confirm this problem?

Originally Posted by SomeJoe

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.

I'm producing a chapter format file which mkvtoolnix accepts. Does mkvtoolnix also accept OGG chapter format files?

Originally Posted by SomeJoe

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.

Well, HD-DVD streams are officially 1080i60 / 1.001, so I guess that justifies the use of NDF timecodes. And the HD DVD specification officially says that NDF timecodes are used. So eac3to should really convert...

Originally Posted by DoomBot

I thought eac3to will let you know if there is audio overlaps with THD tracks even if it can't fix the overlap or is it just a gap it warns you about? Even i did Spider-man 2 keeping the Truehd track and not converting to PCM because i thought there wasn't any overlap since eac3to didn't tell me there was.

I do think that eac3to warns in any case. Maybe with Spiderman 2 the gaps are so small that eac3to didn't found it necessary to complain. TrueHD gaps are really small to begin with, and eac3to only complains if the summed up gaps is bigger than 7ms, IIRC.

Originally Posted by Snowknight26

Small bug I've come across every now and then with eac3to and NeroAacEnc:

When converting/(de)muxing multiple tracks from a random source, one instance of NeroAacEnc doesn't seem to exit, making eac3to hang at the last progress bar. Ending that hung instance of NeroAacEnc causes eac3to to flood the command prompt with
until it it gets to
where x is the size of the file (so the end of it).

I've never seen this happen when doing single audio conversions to AAC, so I suspect it's something to do with eac3to not continuing to feed that hung instance of NeroAacEnc even after all other track operations had finished. Or maybe not.. who knows. Redoing the same command usually fixes it, suggesting that it happens randomly.

How can I reproduce this? I've just tried "eac3to some.wav 1.aac 2.aac" and both AAC files are created just fine.

Originally Posted by Atak_Snajpera

mediainfo shows something interesting

Duration                         : 37mn 25s

Duration                         : 2h 41mn

Originally Posted by tebasuna51

I can confirm the eac3to bug when write the w64 header (work fine with wav input).
The fields RiffLength and DataLength are truncated to 32 bits instead the full 64 bits value (4 GB limit).

Thanks, will be fixed in the next build.

Originally Posted by crasus

Why the difference in the second and third audio tracks, in regards to bitrate and channels upon detection?

My best guess is that the Blu-Ray information records on this Blu-Ray are incorrect. tsMuxeR seems to rely on the Blu-Ray information records, while eac3to always parses the audio bitstream. So if there is a difference, usually eac3to should show the correct information.

Originally Posted by AnryV

1) Decoding by the Arcsoft decoder gives the garbage

As tebasuna51 found out, this seems to be a bug in newer versions of the ArcSoft DTS decoder. The original version 1.1.0.0 seems to handle this fine.

Originally Posted by AnryV

2) Decoding by the Sonic decoder gives normal wavs

For me, decoding your track with Sonic gives me an empty back channel. And funny enough, the runtime is shorter. The chunk of runtime, where the backchannel is supposed to be "spoken", is simply missing. Very weird...

Originally Posted by AnryV

The decoding of TrueHD 6.1 16 bit has the same error in spite of the use of another decoder (libav).

Do you have a short TrueHD 6.1 sample for me? I don't think I've seen a TrueHD 6.1 track yet!

Originally Posted by tebasuna51

But I don't know a official MaskChannel for 6.1 surround, there are two options:
0x013F FL FR FC LFE BL BR BC
0x070F FL FR FC LFE BC SL SR
Note here than the order is a problem, the BC channel must go after/before the Back/Side channels.

When eac3to-ArcSoft decode (without remmaping) the 6.1 put the BC after the Side (maybe ArcSoft consider the channels like Back) and MaskChannel 0x070F. And this is wrong.

You're right. Will be fixed in the next build.