eac3to - audio conversion tool [Archive] - Page 34

madshi

25th November 2007, 19:55

eac3to.exe "G:\Encoding Tools\temp\poseidon.new.dts" "G:\Encoding Tools\temp\poseidon.new.redone.dts"
DTS, 5.1 channels, 1:38:44, 24 bits, 1536kbit/s, 48khz
Creating/writing file "G:\Encoding Tools\temp\poseidon.new.redone.dts"...
Removing DTS zero padding...
Done.

eac3to.exe "G:\Encoding Tools\temp\poseidon.old.dts" "G:\Encoding Tools\temp\poseidon.old.redone.dts"
DTS, 5.1 channels, 1:40:18, 24 bits, 1536kbit/s, 48khz
Creating/writing file "G:\Encoding Tools\temp\poseidon.old.redone.dts"...
Removing DTS zero padding...
Done.

eac3to.exe "G:\Encoding Tools\temp\poseidon.new.redone.dts"
DTS, 5.1 channels, 1:38:36, 24 bits, 1536kbit/s, 48khz

eac3to.exe "G:\Encoding Tools\temp\poseidon.old.redone.dts"
DTS, 5.1 channels, 1:38:35, 24 bits, 1536kbit/s, 48khz
Interesting! Why is there zero padding in your DTS files? Which Surcode version are you using? eac3to normally disables zero padding when automating Surcode.

Are the files with removed padding in sync with the video now?

Snowknight26

25th November 2007, 20:17

Interesting! Why is there zero padding in your DTS files? Which Surcode version are you using? eac3to normally disables zero padding when automating Surcode.

Are the files with removed padding in sync with the video now?

No idea. 1.0.21 according to the help menu.

Edit: poseidon.new.redone.dts synced perfectly. Should I even bother with the other 3 dts files?

TripleH

25th November 2007, 21:19

Hi friends,

I've demuxed the DTS-HD MA track of X-Men: The Last Stand with TSRemux, and here is what eac3to reports:

DTS Master Audio, 6.1 channels, 24 bits, 1536kbit/s, 48khz

Am I getting the full bitrate DTS-HD MA track or only the core ?

As far as I know the 1536kbps is the core.

madshi

25th November 2007, 21:19

poseidon.new.redone.dts synced perfectly. Should I even bother with the other 3 dts files?
Not necessary. If you have problems again in the future, just let me know.

madshi

25th November 2007, 21:20

madshi

25th November 2007, 21:22

eac3to v2.06 released

http://madshi.net/eac3to.zip

* doing FLAC -> FLAC now copies metadata from source to destination file
* MLP files are correctly decoded now (by both Nero and libav/ffmpeg)
* runtime for padded DTS files is shown correctly now

Snowknight26

25th November 2007, 21:28

What was wrong with decoding MLP files?

killa_kid

25th November 2007, 21:29

Will be interesting to hear your results. I'd really like to find a way to automatically calculate the perfect delay value.

well it did seem to have an improvement the problem is that the change was 21ms, so it was barely noticeable.

I have a quick little script I made in JavaScript. You enter the PTM of the EVO, first PTS of video, first PTS of audio, the frame rate that EVOdemux says the video is (in the case of 60 its 30, 59.94 is 29.976,etc) and what the true frame rate is.

So you obviously need to know a bit about the movie before hand, so its not perfect, but I've only found movies with a 23.976 output...granted all of my movies are by American companies and if they were DVD they would be NTSC (in fact I own a couple of them in NTSC DVD :P).

Thunderbolt8

25th November 2007, 21:31

What was wrong with decoding MLP files?
did this explain my batman delay issue?

and which versions affected this? after the new 200 i redecoded all my trueHD tracks again, will I have to do that again now?

TripleH

25th November 2007, 21:33

If you have the Sonic Audio Decoder (v4.3 or newer) installed you'll get the full bitrate DTS-HD MA track decoded.

Although it reports 1536kbps (I have the Sonic Audio Decoder 4.3 installed) ?

Thanks.

madshi

25th November 2007, 22:00

What was wrong with decoding MLP files?
Nothing, I just forgot to add support for that.

did this explain my batman delay issue?
Not at all. We were talking about MLP and not about TrueHD.

madshi

25th November 2007, 22:02

Although it reports 1536kbps (I have the Sonic Audio Decoder 4.3 installed) ?
Ooops, that's a bug in eac3to. But don't worry, it's just a cosmetic issue. Basically eac3to shouldn't show the bitrate at all for DTS-HD Master Audio tracks. You'll still get the full DTS-HD Master Audio track decoded just fine. Just ignore that "1536kbit/s" text.

Snowknight26

25th November 2007, 22:22

Doesn't TrueHD use MLP?

Thunderbolt8

25th November 2007, 22:25

wasnt both the same ? 0o
at least the normal evodemux window tells me truehd, while at the stream window theres always mlp displayed :S

madshi

25th November 2007, 23:02

Dolby bought MLP from Meridian, modified MLP a bit to allow more than 5.1 and named their modificated MLP "TrueHD". It's related to MLP but not the same. The headers differ noticably. HD DVD and Blu-Ray use TrueHD. DVD-Audio used MLP. Maybe HD DVD and Blu-Ray could also use MLP, but so far all tracks I've seen were TrueHD and not MLP. eac3to v2.06 fixed/added MLP decoding. This change had nothing to do with TrueHD decoding.

Snowknight26

25th November 2007, 23:05

Still leaves us with the sync-up-until-the-half-way-mark issues that Thunder (and I) experience. Could it be an EVOdemux problem?

killa_kid

25th November 2007, 23:15

Still leaves us with the sync-up-until-the-half-way-mark issues that Thunder (and I) experience. Could it be an EVOdemux problem?

are you merging (or demuxing) both EVO files into 1? I had the same problems with I didn't make a single file out of them

Thunderbolt8

25th November 2007, 23:18

rebuilt the truehd track as 1 seperate .evo and then demuxed the track from there

killa_kid

25th November 2007, 23:20

what about the video?

Thunderbolt8

25th November 2007, 23:25

rebuilt (vc1)

madshi

25th November 2007, 23:32

Those movies where there are still delay problems, does EvoDemux report timestamp differences there? Can we at least confirm that those movies with identical timestamps for video and audio have all delay problems sorted out?

If only those movies are now problematic where first timestamps differ, maybe we should then collect new information? I mean, everybody who meets such a movie, do a manual sync and report here the delay EvoDemux reported and the manual delay you ended up using. Maybe we can find a pattern... But please report only if you're sure that the delay you're using is near perfect. Posting information where the delay might be 100ms off (or even more) won't help.

madshi

25th November 2007, 23:35

Bourne Supremecy English E-AC3
EvoDemux said: +1001ms
ended up using: +1250ms

Thunderbolt8

25th November 2007, 23:38

yes, timestamps differences. might be the 1st one with timestamps differences for truehd, but am not exactly sure. all the movies with timestamp differences for DD+ were fine with the calculated delay.

batman begins:

Opening file PEVOB_1.EVO
Reading...
File size: 11205 Mbytes.
VOB number 4 contains 2 video , 5 audio and 4 subpicture streams.
PTM of first video frame = 00000D61
PTM of last video frame = 19B28220
Duration = 1:19:50.286
VC-1 video stream 0 found!
First PTS = 00000D61
Dolby TrueHD audio stream 1 found!
First PTS = 000053C3 (+200ms)

killa_kid

25th November 2007, 23:42

Transformers Eng E-AC3
EvoDemux said: 0 (but the video had a delay of 83ms)
ended up using: -104ms

All of my other rips used no delay or the same as EVOdemux. The only difference between Transformers is that the frame rate in EVOdemux is different from the final. The rest have the same EVOdemux frame rate and final frame rate.

madshi

25th November 2007, 23:44

Please only post the information about the first EVO file. The information about the 2nd EVO file is useless. Also which delay did you end up using and how sure are you that the final delay is near perfect? If you're not sure if -200ms or 0ms is correct then the information doesn't help us much. Finally: What are you doing with the video? Are you demuxing and/or reencoding?

Thunderbolt8

25th November 2007, 23:44

hm it definately wont work out with +200 for me :S

I didnt decide for anything yet. was only an information post so far :P

madshi

25th November 2007, 23:48

Transformers Eng E-AC3
EvoDemux said: 0 (but the video had a delay of 83ms)
ended up using: -104ms
Ah, interesting! "-83ms" for the audio would have been the mathematical delay if the video file had a delay of "+83ms". So it seems that for you the mathematical way always works correctly.

Strange enough in your original (not edited) post you listed Bourne Supremecy as working with +1001ms delay. But for me that clearly didn't work. I needed to use +1250ms. That's still confusing the heck out of me.

killa_kid

25th November 2007, 23:52

Ah, interesting! "-83ms" for the audio would have been the mathematical delay if the video file had a delay of "+83ms". So it seems that for you the mathematical way always works correctly.

Strange enough in your original (not edited) post you listed Bourne Supremecy as working with +1001ms delay. But for me that clearly didn't work. I needed to use +1250ms. That's still confusing the heck out of me.

I got -83ms originally but I tried the idea you put in my head earlier today, and it seems to help. The problem is the difference is only 21ms, so its nothing substantial to really tell how its working.

For The Bourne Supremacy, I'm guessing its a dubbed track? If so it could be off for some other reason (bad mastering, etc).

PS: I realized you just wanted to see how we fixed these things, and my original post had things that i didn't need to fix :P

madshi

25th November 2007, 23:57

For The Bourne Supremacy, I'm guessing its a dubbed track? If so it could be off for some other reason (bad mastering, etc).
No, it's the original English track. The German dubbed track had the same timestamps as the video and automatically had perfect sync.

Snowknight26

26th November 2007, 00:01

2 Fast 2 Furious, English DD+ track.
Opening file FEATURE_1.EVO
Reading...
File size: 6569 Mbytes.
VOB number 1 contains 1 video , 4 audio and 4 subpicture streams.
PTM of first video frame = 00000D8E
PTM of last video frame = 0CEB6176
Duration = 0:40:08.323
VC-1 video stream 0 found!
First PTS = 00000D8E
Dolby Digital Plus audio stream 0 found!
First PTS = 00016D78 (+1001ms)

+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?

killa_kid

26th November 2007, 00:05

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

26th November 2007, 00:06

+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

26th November 2007, 00:07

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...... :eek:

killa_kid

26th November 2007, 00:11

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

250ms* happy? ;)

Snowknight26

26th November 2007, 00:12

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

26th November 2007, 01:45

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

26th November 2007, 02:08

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

26th November 2007, 02:21

1ms shouldnt be that bad ;)

nautilus7

26th November 2007, 02:34

I know and actually is less than 1 ms.

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

Thunderbolt8

26th November 2007, 02:36

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

nautilus7

26th November 2007, 02:51

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

26th November 2007, 03:48

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

26th November 2007, 09:43

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

26th November 2007, 10:30

@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

26th November 2007, 11:18

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

26th November 2007, 15:25

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

26th November 2007, 16:10

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.

DTS runtimes still mismatching.
:scared:

madshi

26th November 2007, 16:18

madshi

26th November 2007, 16:19

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

26th November 2007, 16:20

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?