eac3to - audio conversion tool

[nautilus7]

I think madshi deleted some examples from 1st post, but i'm not sure.

A detailed user manual is being written, but don't know where it would be ready for publication. Let's hope it wont take long.

[Thunderbolt8]

wow thanks thats finally what weve been all waiting for I guess.
in the next days Ill go through all my AVC HD DVDs and also blu-rays (using xport to demux and eac3to to remux then), which gave me problems again and will compare the results.

for those who are interested in problematic AVC sources, the ones ive encountered so far are

- babel (HD) -> rainbow frames (but not very often)
- band of brothers 1st EP (HD) -> rainbow frames directly since the beginning for the complete episode (after few secs)
- basic instinct (BD) -> rainbow frames/distorted picture
- equilibrium (HD) -> seeking problems
- ghost in the shell (BD) -> distorted picture
- oldboy (BD) -> distorted picture

those problems all occur using ffdshow. some maybe dont, e.g. the rainbow frames of band of brothers or babel (at least as far as I have been reported) when using another decoder e.g. coreavc, so in this case mkvmerge only partly screws up the remux (since playback is fine with ffdshow from the source .evo). the other problems occur with all tested decoders so far (ffdshow, coreavc, vlc) in this case mkvmerge just made a mess.

[madshi]

Originally Posted by rickardk

eac3to v2.26 hangs halfway through muxing The Machinist (H264).

How can I save the bugreport?
The mail function does not seem to work

Does that error window appear? If yes, the bug report should be in the clipboard. Just open notepad and press Ctrl+V.

Originally Posted by nautilus7

DTSwav files are popular on DTS CDs with 5.1 music.

Do you have a sample for me?

Originally Posted by killa_kid

I just downloaded 2.26 and ran "eac3to -test" and I noticed that it saw Sonic as not installed. I do have it, and 2.25 picks it up just fine.

Argh, that's a bug. Will be fixed in next build.

Originally Posted by bmnot

BTW, did you get a chance to look at the T2 DTS track?

Nope. I don't even remember that you asked me to look at it. It seems I missed your comment? Can you repost it, please?

Originally Posted by bmnot

Also, should we rename the external AVC tracks? from .mpv to .avc?

That's not needed.

[bmnot]

Originally Posted by madshi

Nope. I don't even remember that you asked me to look at it. It seems I missed your comment? Can you repost it, please?

It was via PM. You probably get a lot, so I'll repost here:

The movie that contains the DTS-MA track that I am having problems with is the French Studio Canal release of Terminator 2 Director's Cut. eac3to extracts it fine, but I cannot convert to flac or extract the core. I get the dirty track message.

[nautilus7]

Originally Posted by madshi

Do you have a sample for me?

Yes, it will be up soon.

Originally Posted by bmnot

eac3to extracts it fine, but I cannot convert to flac or extract the core. I get the dirty track message.

That was a bug introduced a few versions ago, but also fixed in a previous version. Do you still have problems?


EDIT: Sample can be found here.

[madshi]

Originally Posted by bmnot

The movie that contains the DTS-MA track that I am having problems with is the French Studio Canal release of Terminator 2 Director's Cut. eac3to extracts it fine, but I cannot convert to flac or extract the core. I get the dirty track message.

Works just fine here with my French Terminator 2 (just retested it to be sure). I think nautilus7 had the right idea. This is a known bug in an older eac3to version. My best guess is that your browser has given you an old eac3to download. Run "eac3to" without any parameters to check which version you have. It must be v2.26. If it's not, clear your browser cache and redownload.

[madshi]

Originally Posted by nautilus7

Sample can be found

Thanks, will check this out later...

[bmnot]

Yes, I am 100% sure it is v2.26.

All I simply did was demux from the original evos with eac3to, not evodemux, and rename to .dtshd.

My command was eac3to t2.dtshd t2.flac. Sonic 4.3 is installed.

When I tried again with 2.26 I think it progressed farther this time, before throwing the error. Before it seemed to get 2/3 of the way, now with 2.26 it seemed to almost reach the end before erroring.

[madshi]

Originally Posted by bmnot

Yes, I am 100% sure it is v2.26.

All I simply did was demux from the original evos with eac3to, not evodemux, and rename to .dtshd.

My command was eac3to t2.dtshd t2.flac. Sonic 4.3 is installed.

When I tried again with 2.26 I think it progressed farther this time, before throwing the error. Before it seemed to get 2/3 of the way, now with 2.26 it seemed to almost reach the end before erroring.

Does the core extraction also fail with v2.26? That wouldn't make much sense because if you successfully demuxed the track with eac3to v2.26, core extraction should also work just fine. Of course you could try to demux and extract the core in one step. But it should really be the same as demuxing first and then extracting the core in a separate step.

As I said, I tested demuxing + core extraction half an hour ago with the French Terminator 2 HD DVD with v2.26 and everything worked just fine for me.

If the progress position where it throws the error changes all the time then I'd say that your PC is unstable because there's not really any way that this could should happen. Maybe your CPU is overclocked too much? Or maybe your harddisk needs a scandisk?

[rickardk]

Good news!
No more rainbow frames in Ratatouille, War and Revlover (not watched from beining to end though...but I wrote down timecodes that I checked).

Perfect seekable.

But CoreAVC decoding makes ffdshow TELL (not playback) the wrong framerate for 23.976fps sources.

eac3to HD DVD H264 muxing:
25fps

eac3to HD DVD H264 muxing (pulldown stripped with h264info)
25fps

eac3to Blu-ray H264 muxing:
25fps



mkvmerge HD DVD H264 muxing:
29.97fps

eac3to HD DVD H264 muxing (pulldown stripped with h264info)
23.976fps

mkvmerge Blu-ray H264 muxing:
23.976fps

The default duration is however: 41.708ms (23.976fps) when opened in mkvinfo.


The Machinist:
www.earselect.se/bugreport.txt

Seems like eac3to takes up all my memory. Allocates like 2GB then hangs.

[madshi]

Originally Posted by rickardk

No more rainbow frames in Ratatouille, War and Revlover [...].

Perfect seekable.

Originally Posted by rickardk

But CoreAVC decoding makes ffdshow TELL (not playback) the wrong framerate for 23.976fps sources.

eac3to HD DVD H264 muxing:
25fps

eac3to HD DVD H264 muxing (pulldown stripped with h264info)
25fps

eac3to Blu-ray H264 muxing:
25fps



mkvmerge HD DVD H264 muxing:
29.97fps

eac3to HD DVD H264 muxing (pulldown stripped with h264info)
23.976fps

mkvmerge Blu-ray H264 muxing:
23.976fps

I guess the last 3 entries were all supposed to read "mkvmerge"?

Originally Posted by rickardk

The default duration is however: 41.708ms (23.976fps) when opened in mkvinfo.

Not sure what's going on there. What is the exact DirectShow filter graph you're using and the exact setup of the filters?

Originally Posted by rickardk

The Machinist:
www.earselect.se/bugreport.txt

Seems like eac3to takes up all my memory. Allocates like 2GB then hangs.

The Machinist seems to have extremely rare IDR frames. I already thought that Equilibrium was extreme in that matter, but The Machinist seems to easily top Equilibrium. Anyway, it should be fixable on the cost of decreased performance. Currently I'm doing everything in RAM. It seems that I need to store some things on the harddisk temporarily...

[Jaja1]

eac3to v2.26 released

* external raw h264/AVC tracks can now be muxed directly to Matroska

Does this mean I can use xport to demux a AVC blu-ray and remux xport's output to mkv with eac3to?

[rickardk]

Yes, mkvmerge for the last 3. Sorry.

haali splitter->coreavc->ffdshow->evr


ffdshow does nothing in this graph except reads the fps.
CoreAVC: preferred decoder, deinterlacing hardware, aggressive deinterlacing


Media Control then reads the frame rate from ffdshow to set the correct refresh rate.

[madshi]

Originally Posted by Jaja1

Does this mean I can use xport to demux a AVC blu-ray and remux xport's output to mkv with eac3to?

Yes !

[madshi]

I've checked out the DTSWAV sample provided by nautilus7 and it looks awful to me. I see no good way to automatically detect whether the WAV file contains PCM or DTS. Also I don't have any information about how the DTS file is stored exactly in the WAV file. At least the DTS signature seems to be missing. So I really don't have much fun adding support for DTSWAV right now. Maybe I'll change my mind if someone has an exact specification?

[tebasuna51]

Originally Posted by madshi

I've checked out the DTSWAV sample provided by nautilus7 and it looks awful to me. I see no good way to automatically detect whether the WAV file contains PCM or DTS. Also I don't have any information about how the DTS file is stored exactly in the WAV file. At least the DTS signature seems to be missing. So I really don't have much fun adding support for DTSWAV right now. Maybe I'll change my mind if someone has an exact specification?

Really I don't think you need support dtswav files because there are free tools to convert to standard dts (BeSplit, DtsParser,...) or to transcode directly to others formats (Foobar2000, BeHappy, ...).

BTW, some info:
the dtswavsample.wav from Nautilus7 have a wrong wav header (RiffLength and DataLenght wrong, AudioFormat 1 = pcm int). Seems Nautilus7 cut the firts bytes from a file 455114796 bytes long.

I see other dtswav with header with correct RiffLength and DataLenght but always AudioFormat 1 = pcm int.

When a wav is used like container the AudioFormat field must define the data format. If a soft found in a file, with wav extension, a correct pcm int header, can't know the data are dts compressed and output noise.

To use dtswavsample.wav with Foobar or BeHappy we need change the name to dtswavsample.dts

To decode a dtswav.dts first we need ignore the wav header (first 44 bytes) and now begin the dts, but the more frequent DTS signature is DCA_MARKER_14B_LE instead the standard DCA_MARKER_RAW_BE

See dca.h in libacodec lib:

#define DCA_MARKER_RAW_BE 0x7FFE8001
#define DCA_MARKER_RAW_LE 0xFE7F0180
#define DCA_MARKER_14B_BE 0x1FFFE800
#define DCA_MARKER_14B_LE 0xFF1F00E8

Or dts_syncinfo function in parse.c from libdts used in NicAudio decoder with AviSynth (BeHappy).

The data seems 14 bits little-endian instead 16 bits big-endian.

EDIT: There are many free samples at http://www.sr.se/cgi-bin/mall/artike...Artikel=740607

[rickardk]

Maybe it's a problem with CoreAVC? I guess I could contact the developers?

When using other H264 decoders and ffdshow donwstreams the correct frame rate is read. (But that does not explain why a diffrent frame rate is shown when H264 is muxed with mkvmerge)

[madshi]

Originally Posted by rickardk

Maybe it's a problem with CoreAVC? I guess I could contact the developers?

When using other H264 decoders and ffdshow donwstreams the correct frame rate is read. (But that does not explain why a diffrent frame rate is shown when H264 is muxed with mkvmerge)

I don't know right now why eac3to h264 muxes show a different framerate compared to mkvtoolnix muxes in CoreAVC. I see no reason why that should be the case. But it might very well be a CoreAVC bug. Let me check that before you contact the developers, just to be safe...

[Thunderbolt8]

regarding coreavc, i might have a potential problem with the 'the illusionist' BD AVC stream: at one place in the movie theres a little glitch.
now the question is whether this could really be an eac3to muxing problem or not, since its really only this one instance of 5-6 frames in the whole movie, where it occurs, the complete rest is fine. so this could possibly be due to a ripping problem.

I demuxed the video with xport 1.01 and muxed it to .mkv using eac3to 2.26 (and remuxed with mkvmerge together with the audio afterwards, but doesnt matter, the problem is in both .mkv files). with coreavc I get this problem no matter whether I use eac3to or manually mux the video with mkvmerge only.
with ffdshow im not sure atm, because I deleted the mkvmerge video mux and therefore cant check how that result was. however, the glitch is not present when using eac3to to mux the video to .mkv.

so in the end it could as well be a ripping or coreavc decoder only problem, which I dont really mind to be frank since I actually dont use coreavc, only ffdshow. but since theres a slight possiblity it could nevertheless be a little problem of eac3to's muxing, which then could also occur when using ffdshow in other movies, I thought I mention it.

http://www.image-load.eu/out.php/i29...0303173521.PNG
http://www.image-load.eu/out.php/i29...0303173526.PNG
http://www.image-load.eu/out.php/i29...0303173530.PNG

[madshi]

Originally Posted by tebasuna51

Really I don't think you need support dtswav files because there are free tools to convert to standard dts (BeSplit, DtsParser,...) or to transcode directly to others formats (Foobar2000, BeHappy, ...).

If it's easy to support then I'll add it. Doesn't harm...

Originally Posted by tebasuna51

When a wav is used like container the AudioFormat field must define the data format. If a soft found in a file, with wav extension, a correct pcm int header, can't know the data are dts compressed and output noise.

Well, if the very first 4 bytes of the WAV data contain a valid DTS signature then I think it's safe to say that it's DTS and not WAV, right? I mean, the chance that a real WAV file randomly has exactly those DTS signature bytes in the first 4 bytes of the PCM data is extremely slim, especially because the beginning of a WAV file is usually silent. What do you think?

Originally Posted by tebasuna51

To decode a dtswav.dts first we need ignore the wav header (first 44 bytes) and now begin the dts, but the more frequent DTS signature is DCA_MARKER_14B_LE instead the standard DCA_MARKER_RAW_BE

See dca.h in libacodec lib:

#define DCA_MARKER_RAW_BE 0x7FFE8001
#define DCA_MARKER_RAW_LE 0xFE7F0180
#define DCA_MARKER_14B_BE 0x1FFFE800
#define DCA_MARKER_14B_LE 0xFF1F00E8

Cool - thanks!

Originally Posted by tebasuna51

Or dts_syncinfo function in parse.c from libdts used in NicAudio decoder with AviSynth (BeHappy).

The data seems 14 bits little-endian instead 16 bits big-endian.

Are the remaining 2 bits zeroed out?