eac3to - audio conversion tool

[killa_kid]

Originally Posted by madshi

No, it's the original English track. The German dubbed track had the same timestamps as the video and automatically had perfect sync.

hmmmm...the first time I watched my rip of The Bourne Identity, it was not my computer, lying on a couch, now that I am watching it from my monitor up close I am seeing some sync issues. I tried adding a 150ms delay as it was playing, and it seems to be fixing the issues. With my already present 1001ms + 150ms = 1250ms delay. It looks like there may be more to this then I can see. I'm gonna check all of my rips now much much closer

[madshi]

Originally Posted by Snowknight26

+1001 works for the beginning, but buy the end, its off. Would need +1350 at the end.
Since I'm reencoding to x264 as 23.976, could that be whats causing it? If so, why aren't my other encodes off.. like Poseidon?

If +1001 works for the beginning that's all what is important for eac3to. If the audio is out of sync at the end of the movie that probably has something to do with how you do the reencoding. As was said before, you should join the EVO files before you do the reencoding. Don't know if you already did that.

[madshi]

Originally Posted by killa_kid

hmmmm...the first time I watched my rip of The Bourne Identity, it was not my computer, lying on a couch, now that I am watching it from my monitor up close I am seeing some sync issues. I tried adding a 150ms delay as it was playing, and it seems to be fixing the issues. With my already present 1001ms + 150ms = 1250ms delay. It looks like there may be more to this then I can see. I'm gonna check all of my rips now much much closer

1001ms + 150ms = 1250ms? Ehm......

[killa_kid]

Originally Posted by madshi

1001ms + 150ms = 1250ms? Ehm......

250ms* happy?

[Snowknight26]

Originally Posted by madshi

If +1001 works for the beginning that's all what is important for eac3to. If the audio is out of sync at the end of the movie that probably has something to do with how you do the reencoding. As was said before, you should join the EVO files before you do the reencoding. Don't know if you already did that.

Would that affect the video, audio, or both.. and when, demuxing or reencoding?


Edit:
Also:

eac3to.exe "G:\Encoding Tools\temp\2fast.dd+.mpa" 2fast.dts
E-AC3, 5.1 channels, 1:47:35, 1536kbit/s, 48khz, dialnorm: -27dB
Removing dialog normalization...
Decoding with DirectShow (Nero Audio Decoder 2)...
Disabling DRC for Nero (E-)AC3 decoding...
DirectShow reports 5.1 channels, 24 bits, 48khz
Writing WAVs...
Creating/writing file "2fast.L.wav"...
Creating/writing file "2fast.R.wav"...
Creating/writing file "2fast.C.wav"...
Creating/writing file "2fast.LFE.wav"...
Creating/writing file "2fast.SL.wav"...
Creating/writing file "2fast.SR.wav"...
Surcode encoding successfully started. Please wait...
Closing Surcode...
Done.

eac3to.exe 2fast.dts
DTS, 5.1 channels, 1:47:35, 24 bits, 1536kbit/s, 48khz

eac3to.exe 2fast.dts 2fast.redone.dts
DTS, 5.1 channels, 1:47:35, 24 bits, 1536kbit/s, 48khz
Creating/writing file "2fast.redone.dts"...
Removing DTS zero padding...
Done.

eac3to.exe 2fast.redone.dts
DTS, 5.1 channels, 1:48:00, 24 bits, 1536kbit/s, 48khz

DTS runtimes still mismatching.

[nautilus7]

I am trying to decode a trueHD track with ffmpeg. I get this message:

C:\Tools>eac3to matrix.3.thd matrix.3.ffmpeg.wavs -libav
TrueHD, 5.1 channels, 48khz, dialnorm: -27dB
Writing WAVs...
Removing dialog normalization...
Creating/writing file "matrix.3.lib.24bit.L.wav"...
Creating/writing file "matrix.3.lib.24bit.R.wav"...
Creating/writing file "matrix.3.lib.24bit.C.wav"...
Creating/writing file "matrix.3.lib.24bit.LFE.wav"...
Creating/writing file "matrix.3.lib.24bit.SL.wav"...
Creating/writing file "matrix.3.lib.24bit.SR.wav"...
-------------------------------------------------------------------------------[
mlp @ 68A442E0]End of stream indicated
[mlp @ 68A442E0]Substream 1 parity check failed
[mlp @ 68A442E0]Substream 1 checksum failed
[mlp @ 68A442E0]Substream 1 length mismatch.
This audio track contains only 16 bit of information.
The zero bytes were successfully removed.
Done.

The output file looks ok, but it is 1 ms sorter than the one decoded with nero decoder. This ms is missing from the end of the track.

There are also some different bytes at the start of the decoded tracks (nero vs ffmpeg).

Apart from these 2 points both decoded tracks are identical.

Here's a sample: http://rapidshare.com/files/72300511/sample.zip.html

[nautilus7]

I have dts runtime displayed wrong here too.

C:\Tools>eac3to matrix.3.dts
DTS, 5.1 channels, 2:09:46, 24 bits, 1536kbit/s, 48khz

C:\Tools>eac3to matrix.3.dts matrix.3.padded.dts
DTS, 5.1 channels, 2:09:46, 24 bits, 1536kbit/s, 48khz
Creating/writing file "matrix.3.padded.dts"...
Done.

C:\Tools>eac3to matrix.3.padded.dts
DTS, 5.1 channels, 2:09:46, 24 bits, 1536kbit/s, 48khz

C:\Tools>eac3to matrix.3.c.wav
WAV, 1.0 channels, 2:09:16, 24 bits, 48khz

The correct runtime is 2:09:16. The dts was already padded, so nothing was changed.

[Thunderbolt8]

1ms shouldnt be that bad

[nautilus7]

I know and actually is less than 1 ms.

It's all about development of the ffmpeg/eac3to.

[Thunderbolt8]

there could even be 1 ms difference when muxing flac into mka. so I guess this is just normal

[nautilus7]

I wouldn't care about this at all, but i got an error (?) message from eac3to when decoding. So i thought why not make a sample for madshi?

[Thunderbolt8]

I guess we can cancel that batman thing from the list.
I just redid the flac track with 205 and its fine now with 200ms delay. dunno what happened before, maybe I just saw ghosts :S

[puppydg68]

I'm trying to get eac3to running, I'm running nero 7
and I keep getting the message
Disabling DRC for Nero (E-)AC3 decoding... then lines go across the screen and then it exits. It does not continue.
is there a specific version of nero 7 I need?

I tried a nero lite version and it said getting nero audio decoder 2 instance failed.

[xkodi]

@madshi

several things about the MLP (DVD-Audio) support:

1) there are 3 types of channel order for 5.1 MLP files:

ID 12: Group 1 (Lf, Rf), Group 2 (C, LFE, Ls, Rs)
ID 17: Group 1 (Lf, Rf, C), Group 2 ( LFE, Ls, Rs)
ID 20: Group 1 (Lf, Rf, Ls, Rs), Group 2 (C, LFE)

and they are all valid channel order for 5.1 MLP, decoded to WAV, they all produce the same WAV file with the valid channel order for 5.1 WAV files: Lf, Rf, C, LFE, Ls, Rs.

but eac3to 2.06 reports:

C:\eac3to206>eac3to.exe c:\mlp51_id12.mlp
MLP, 5.1 channels, 16 bits, 44.1khz

C:\eac3to206>eac3to.exe c:\mlp51_id17.mlp
MLP, 5.1 channels, 16 bits, 44.1khz

C:\eac3to206>eac3to.exe c:\mlp51_id20.mlp
MLP, 5.1 wrong order channels, 16 bits, 44.1khz

ID 20 order is wrong for WAV files, but not for MLP, so "5.1 wrong order channels" doesn't seem right to me.

2) with Nero decoder all of the samples: mlp51_id12.mlp, mlp51_id17.mlp, mlp51_id20.mlp are decoded, but the output is different for mlp51_id20.mlp, probably it produces WAV with channel order Lf, Rf, Ls, Rs, C, LFE instead of the correct one Lf, Rf, C, LFE, Ls, Rs. it's important, because most of the DVD-Audio discs use ID20, ID12 and ID17 are very rare.

3) with -libav switch all of the above samples produce:

mlp @ XXXXXXXX]Lossless check failed - expected 0, calculated 7
The libav decoder output an unexpected bitdepth.
The WAV writer didn't receive any audio data.

and no output at all, i don't know why because i have ffmpeg patched with one of the first MLP patches and it decodes all of the samples without complaining about the checksums, so maybe with the newest ffmpeg MLP patches, something is broken and previous versions are better to use at the moment, because there is no problem with the checksums according to Surecode MLP:

Verify: stream "C:\mlp51_id20.mlp" passed.

here are the samples: http://xkodi.svobodno.com/mlp51/

[TripleH]

Another problem here.

I converted X-Men: The Last Stand DTS-HD Master Audio track to FLAC, and the playing didn't go well, so I put the FLAC file in mka container and now it is playable (If I play the flac file as it is I get nothing but static rain/snow noise).

Anyway, now FFDShow decodes and it is fine, but FFDShow reports 16bit while it should be 24bit:

Input Description: 48000 Hz, 8 channels flac (libavcodec)
Output Description: 48000 Hz, 6 channels 16-bit integer

I checked the output section and the support for 24bit is checked.

How can I make it do right ?

Edit: I tried to uncheck the 16bit option and only leave the 24bit option checked and now it reports 24-bit integer.

Do you think it is upsampling the audio by itself instead of decoding it as truly 24bit ?

[xkodi]

about

The libav decoder output an unexpected bitdepth.

problem, that i mentioned in my previous post:

when i do:

./configure --disable-static --enable-shared
make

to build avcodec.dll, the newly build avcodec.dll still doesn't work with the samples above and eac3to produces the same error, but ffmpeg works without complaining.

when i just do:

./configure
make

avcodec.dll is not built and again ffmpeg works with the samples without complaining.

so, ffmpeg works with the samples in both cases: when it's a static build and when uses avcodec.dll, but the same avcodec.dll, that works with ffmpeg and the samples, doesn't work with eac3to and gives

The libav decoder output an unexpected bitdepth.

error, so hope madshi will find a solution to that problem.

p.s.
the problem is with all 16bit MLP files, when the file is 24bit, then eac3to works.

[madshi]

Originally Posted by Snowknight26

Would that affect the video, audio, or both.. and when, demuxing or reencoding?

I've never done reencoding, so I can't say anything about that.

Originally Posted by Snowknight26

DTS runtimes still mismatching.

[madshi]

Originally Posted by nautilus7

I am trying to decode a trueHD track with ffmpeg. I get this message:

C:\Tools>eac3to matrix.3.thd matrix.3.ffmpeg.wavs -libav
TrueHD, 5.1 channels, 48khz, dialnorm: -27dB
Writing WAVs...
Removing dialog normalization...
Creating/writing file "matrix.3.lib.24bit.L.wav"...
Creating/writing file "matrix.3.lib.24bit.R.wav"...
Creating/writing file "matrix.3.lib.24bit.C.wav"...
Creating/writing file "matrix.3.lib.24bit.LFE.wav"...
Creating/writing file "matrix.3.lib.24bit.SL.wav"...
Creating/writing file "matrix.3.lib.24bit.SR.wav"...
-------------------------------------------------------------------------------[
mlp @ 68A442E0]End of stream indicated
[mlp @ 68A442E0]Substream 1 parity check failed
[mlp @ 68A442E0]Substream 1 checksum failed
[mlp @ 68A442E0]Substream 1 length mismatch.
This audio track contains only 16 bit of information.
The zero bytes were successfully removed.
Done.

The output file looks ok, but it is 1 ms sorter than the one decoded with nero decoder. This ms is missing from the end of the track.

There are also some different bytes at the start of the decoded tracks (nero vs ffmpeg).

Apart from these 2 points both decoded tracks are identical.

Here's a sample: http://rapidshare.com/files/72300511/sample.zip.html

Thanks, I'll forward this to the MLP/TrueHD decoder author.

I can only reproduce the problem with the end of the file, though. Your "start.thd" sample decodes identically with Nero/ffmpeg for me. Can you recheck the start, please?

[madshi]

Originally Posted by Thunderbolt8

I guess we can cancel that batman thing from the list.
I just redid the flac track with 205 and its fine now with 200ms delay. dunno what happened before, maybe I just saw ghosts :S

That's good to know, thanks. So it seems that for now the mathematical delay calculation (based on first timestamps) works alright. The only remaining question is whether we need to multiply that value by "29.97 / 23.976" or not.

[nautilus7]

Concerning trueHD sync issues...

I am very confused with The Matrix REV HD DVD. I have the original HD DVD and an encode of it which comes with dts sound. I didn't make this encode, but i know that the dts track was made from lossless trueHD track, with an eac3to version prior to trueHD Dialog Normalization fix. So i thought of making a flac track in order to replace the dts track.

The result is very confusing... The flac track is in sync in the 1st half (i guess the part that came from the first evo file), but de-sync (needs about 150 ms of delay) in the 2nd part. The really strange thing is that when i decoded both the dts and the flac tracks to wav and opened them in audacity, they had a constant 10 ms offset from beginning to end!!! Of course the dts track that was original included in the encode is in sync with the video.

Can you give me a logical explanation, please?