eac3to - audio conversion tool

[poisondeathray]

OK, I've installed the latest release of MKVmerge and it still gives me an error message and says it is an unknown type when I try to mux the TrueHD audio of Iron man.

Am I missing something?

The_Keymaker

The beta version is supposed to add support. Scroll down for more info, and download link
http://forum.doom9.org/showthread.php?t=120648&page=42

[sucker]

Just extract your TrueHD into individual mono WAVs instead, and use the MUI Generator to create your multi-channel PCM that way. (Open the MUI Generator, select your _LEFT_ channel WAV in the ES File box. Then select 'Use Multi LPCM function' and click Input LPCM Files. You can then select the rest of your files and it will create a .VES file you can drop into Scenarist.)

i´m pretty new to Scenarist and didn´t notice this possibility, thx alot for the info
btw is eac3to able to apply delays to TrueHD streams when demuxing to TrueHD or only when the TrueHD is beeing converted at the same time to PCM/WAV...?

[The_Keymaker]

The beta version is supposed to add support. Scroll down for more info, and download link
http://forum.doom9.org/showthread.php?t=120648&page=42


Found it!

Thanks Poisondeathray :thanks:

[AnryV]

Because of Nero's limitation to 5.1 channels...

How it is connected with the asked question about bitdepth?
I wish to be assured that libav/ffmpeg decoder does not lose the information.

[nurbs]

It doesn't lose quality. Nero will output 24 bit no matter what the actual bitdepht of the TrueHD file is.

[rik1138]

He was asking about libav/ffmpeg. Can libav output 24bit wavs if the source really is full 24bit?

Is there an easy way to determine if a 24-bit WAV really is 24-bit (and not just padded)?

[TinTime]

He was asking about libav/ffmpeg. Can libav output 24bit wavs if the source really is full 24bit?

Yes :) It is decoding to 24 bits here. It's just when it reaches the end that eac3to confirms that only 16 bits are used so it runs a second pass.

Is there an easy way to determine if a 24-bit WAV really is 24-bit (and not just padded)?

Just run it through eac3to:
eac3to.exe input.wav output.wav

If it's got superfluous bits eac3to will strip them. It's probably worth trying this with AnryV's output from the Nero decoder.

@AnryV - Try converting to a single wav with Nero and then running that wav through eac3to again.

I would have expected this to happen automatically with the output from Nero in this case but maybe it doesn't. I thought libav and Nero behave identically, except for the 5.1 channel limitation for Nero. I may be wrong about this though. I'm confident that madshi will have picked the best decoder for the job though so I'd stick with libav. It doesn't say in the eac3to help that for best TrueHD decoding you need Nero. It used to IIRC, before libav TrueHD decoding was refined.

[AnryV]

@AnryV - Try converting to a single wav with Nero and then running that wav through eac3to again.


eac3to v3.15
command line: eac3to eng.C.wav eng.C1.wav
------------------------------------------------------------------------------
WAV, 1.0 channels, 1:55:25, 24 bits, 1152kbps, 48khz
Reading WAV...
Writing WAV...
Creating file "eng.C1.wav"...
The original audio track has a constant bit depth of 24 bits.
eac3to processing took 1 minute, 27 seconds.
Done.

eng.C.wav was created by Nero decoder as mentioned above.

???:confused:

[kastrom]

I'm trying to rip Total Recall from HD-DVD and I received a gaps file and have huge sync problems. I have run it again and the log files says it uses the gap file but there is still over three seconds differences between picture and the sound. Is is possible to fix the sync?

/Kent

[The_Keymaker]

OK, I loaded the beta version of MKVtoolnix (MKVmerge) and muxed the Iron man TrueHD+AC3 audio and Video.

However, when I attempted to play back the file using Zoom Player, only the VIDEO showed up in Zoom Player. An audio stream was not found.

I'm assuming this is an MKVmerge issue and not an eac3to issue since I was able to play the TrueHD+AC3 file fine as a standalone file (i.e., not in a MKV container).

I'll take this issue up on the MKVtoolnix forum. Just wanted to share my experience in case any is trying to do the same thing.

[Mark_A_W]

OK, I loaded the beta version of MKVtoolnix (MKVmerge) and muxed the Iron man TrueHD+AC3 audio and Video.

However, when I attempted to play back the file using Zoom Player, only the VIDEO showed up in Zoom Player. An audio stream was not found.

I'm assuming this is an MKVmerge issue and not an eac3to issue since I was able to play the TrueHD+AC3 file fine as a standalone file (i.e., not in a MKV container).

I'll take this issue up on the MKVtoolnix forum. Just wanted to share my experience in case any is trying to do the same thing.


At a wild guess you are using the Haali Splitter? The Haali Splitter does not "see" TrueHD streams. You need to use the MPC-HC Mpeg2 splitter (or MPC HC itself, using the internal splitter).

Or convert to FLAC. FLAC just works.

[leeperry]

Is there an easy way to determine if a 24-bit WAV really is 24-bit (and not just padded)?
both Wavelab & Ozone will show you whether all the bits are actually in use...at least it tells you right away, no need to wait 10 minutes ;)

[The_Keymaker]

At a wild guess you are using the Haali Splitter? The Haali Splitter does not "see" TrueHD streams. You need to use the MPC-HC Mpeg2 splitter (or MPC HC itself, using the internal splitter).

Or convert to FLAC. FLAC just works.

Yes you are correct I am using the haali splitter. I will acquire and and try the MPC HC Splitter.

Also, I've tried FLAC but it just does not sound the same (in my system) as bitstream (TrueHd, DD, DTS etc.). I've done some research since I discovered this fact and it appears some think it has to do with excessive jitter wrought by the HDMI transmission interface ( I use HDMI from my HTPC rather than SPDIF). This jitter apparently is less of an issue when bit streaming since the way bitstreams are decoded is less dependent on the master clock.

See this link (post #6016): http://www.avsforum.com/avs-vb
/showthread.php?p=16205544#post16205544

And here: http://www.avsforum.com/avs-vb/showthread.php?t=1134289

UPDATE: i installed the MPC HC splitter (from here: http://sourceforge.net/project/showfiles.php?group_id=170561&package_id=264678) but still no joy. Can someone that has successfully muxed (with video) and played back a TrueHD track post their graph? You can PM me if you don't want to tard up the eac3to thread, although there may be others interested as well.

[Mark_A_W]

Yes you are correct I am using the haali splitter. I will acquire and and try the MPC HC Splitter.

Also, I've tried FLAC but it just does not sound the same (in my system) as bitstream (TrueHd, DD, DTS etc.). I've done some research since I discovered this fact and it appears some think it has to do with excessive jitter wrought by the HDMI transmission interface ( I use HDMI from my HTPC rather than SPDIF). This jitter apparently is less of an issue when bit streaming since the way bitstreams are decoded is less dependent on the master clock.

See this link: http://www.avsforum.com/avs-vb
/showthread.php?p=16205544#post16205544

And here: http://www.avsforum.com/avs-vb/showthread.php?t=1134289

UPDATE: i installed the MPC HC splitter (from here: http://sourceforge.net/project/showfiles.php?group_id=170561&package_id=264678) but still no joy. Can someone that has successfully muxed (with video) and played back a TrueHD track post their graph? You can PM me if you don't want to tard up the eac3to thread, although there may be others interested as well.


Actually, I think the latest Haali splitter may "see" TrueHD, but it doesn't label it (which is ok if it's the only audio stream present).

[TinTime]

both Wavelab & Ozone will show you whether all the bits are actually in use...at least it tells you right away, no need to wait 10 minutes ;)

But if you have a 24 bit wav file with 24 valid bits per sample set in the header how can Wavelab & Ozone tell for sure without spending 10 minutes reading the whole file?

I suppose they can read the first few seconds and see what that looks like, but the only sure-fire way to check all the bits is to check all the bits!

[TinTime]

What bit depth the original track has? 24 or 16?

I've tried two TrueHD tracks (16 bit from "I Am Legend" and 24 bit from "Cloverfield") with both decoders and couldn't replicate your problem. How did you create the .thd file? What movie did it come from and how did you demux it, or have you encoded it yourself?

[AnryV]

I've tried two TrueHD tracks (16 bit from "I Am Legend" and 24 bit from "Cloverfield") with both decoders and couldn't replicate your problem. How did you create the .thd file? What movie did it come from and how did you demux it, or have you encoded it yourself?
"Appaloosa."
.thd demuxed by eac3to.

[dstoe]

rather old, but still relevant:

Thank you. Right now there's no way to donate. Maybe I'll make that available later...

any update on this?

[leeperry]

But if you have a 24 bit wav file with 24 valid bits per sample set in the header how can Wavelab & Ozone tell for sure without spending 10 minutes reading the whole file?

I suppose they can read the first few seconds and see what that looks like, but the only sure-fire way to check all the bits is to check all the bits!
both Ozone & Wavelab have bit meters, but sure this won't be as accurate as checking the whole file...but if the bottom bits lighten up, it's a good guess that you do have a true 24bit file :o

from the Ozone help file :

http://www.image-load.eu/out.php/t156901_ozone.png (http://www.image-load.eu/out.php/i156901_ozone.png)

[leeperry]

if you see this, this is 24bit 100% sure and it took 10 secs to find out :)

http://www.image-load.eu/out.php/i156904_24.png

[TinTime]

"Appaloosa."
.thd demuxed by eac3to.

According to this list (http://www.avsforum.com/avs-vb/showthread.php?t=760714) Appaloosa's TrueHD track is 16 bit, so it looks like something funny is happening with Nero decoding here. This is really a question for madshi. Or stick with the default decoding which seems to be correct in this case.

if you see this, this is 24bit 100% sure and it took 10 secs to find out :)

http://www.image-load.eu/out.php/i156904_24.png

You're quite right - I didn't think of it that way around. If the file is genuinely 24 bit you can find out immediately. If it's 16 bit you need to read the whole lot to confirm.

[leeperry]

If it's 16 bit you need to read the whole lot to confirm.
not really, if it's 16bit it will look like this :

http://www.image-load.eu/out.php/i156906_16.png

you can use Ozone in ffdshow :)

[TinTime]

not really, if it's 16bit it will look like this :

http://www.image-load.eu/out.php/i156906_16.png

you can use Ozone in ffdshow :)

If you've got a film with something like an introduction from the director at the beginning, and the audio introduction is 16 bit and the main movie audio is 24 bit, then what does Ozone show you when you're watching the intro? If it's the above picture then it would lead to an incorrect conclusion about the full audio track.

I'm being kind of pedantic here (but what the hell :devil:) because I don't know if such a soundtrack exists (although there's no reason why it couldn't). If you think that a 24 bit audio file is only 16 bit then the only way to confirm it is to read the file until you find a > 16 bit sample. If it's entirely 16 bit then you'll end up reading the whole file.

[leeperry]

If you've got a film with something like an introduction from the director at the beginning, and the audio introduction is 16 bit and the main movie audio is 24 bit
haha sure, but Ozone works in realtime in ffdshow....so you can seek a number of times and if the bottom 8bit remain turned off you know it's 16bit, anyway I was simply answering to rik1138 who was seeking an easy way to find out ;)

Is there an easy way to determine if a 24-bit WAV really is 24-bit (and not just padded)?

[leeperry]

just a last word on bit meters...you'll have to use Wavelab because the winamp plugins work in 16int only in ffdshow audio(even if you only check 32float processing) :o

here's a test on a 24/96 stereo FLAC, captured via graphedit.
left side is ffdshow audio w/ 3 filters : volume/mixer/EQ, right side is w/ a winamp2 plugin afterwards.

http://www.image-load.eu/out.php/i156949_eeeeq.png

[Blue_MiSfit]

Is cool!

@Madshi:

I have found an unusual MPEG Program Stream that contains MPEG-2 video an AC3 audio, but eac3to doesn't recognize the audio stream (thankfully I was able to use DGIndex to extract the AC3). It complains like this:

Z:\>eac3to Alaska-SpiritoftheWild.mpg
MPG, 1 video track
1: MPEG2, 1080p24 (16:9)
v01 The video framerate is correct, but rather unusual.


The MPEG-2 is indeed 24.0fps exactly, but it seems after this point eac3to gives up.

Here's a 25mb sample:

http://www.mediafire.com/?sharekey=47de74c3f78774007f7ec40ada4772a66f2980d865a0ad6c5621d66e282a0ee8

Please let me know if you need more!

~MiSfit

[odin24]

Two new features added: Sony wave64 support and mkv chapters.

While demuxing BDs with MeGUI (which uses eac3to), should I use W64 for PCM tracks. I'm really only familiar with the three main HD audio extensions, MeGUI doesn't offer a PCM extension.

Thanks.

[tebasuna51]

While demuxing BDs with MeGUI (which uses eac3to), should I use W64 for PCM tracks. I'm really only familiar with the three main HD audio extensions, MeGUI doesn't offer a PCM extension.

Yes, w64 is like wav file (PCM data with a header) but without the wav limits (2/4 GB).

With multichannel audio and high bitdepth/samplerate is easy reach this wav limits then the w64 header is recommended.

NicAudio AviSynth plugin can read w64 files then can be used with MeGUI also.

[tebasuna51]

(Seems TsMuxeR 1.9.1 still don't work with w64 files)

@madshi. Seems there are a bug in eac3to with w64 files like the recent with wav files.

This file, created by eac3to, is not recognized by eac3to. (work fine with other softs):

6x321.w64 (http://www.sendspace.com/file/h196ug)

[madshi]

Sorry for the lack of replies lately. I'll reply to all questions and comments and get back to eac3to bug fixing (at least) this or next weekend.

If you're interested in why eac3to development has been slow recently, you may want to look here:

http://forum.doom9.org/showthread.php?t=146228

:D

[TinTime]

If you're interested in why eac3to development has been slow recently, you may want to look here:

http://forum.doom9.org/showthread.php?t=146228

:D

Now that looks very interesting...

If madVR is half as good as eac3to you're on to a winner.


Keep up the good work! :thanks:

[jolson]

Tried to convert a 5.1 TrueHD file to 1.5Mbit DTS, but got an error:

eac3to v3.12
command line: "C:\Program Files\eac3to\eac3to.exe" th.ac3 dm.dts -resampleto48000 -1536
------------------------------------------------------------------------------
TrueHD/AC3, 5.1 channels, 96khz, dialnorm: -27dB
(embedded: AC3, 5.1 channels, 640kbps, 48khz, dialnorm: -27dB)
Extracting TrueHD stream...
Removing TrueHD dialog normalization...
Decoding with libav/ffmpeg...
Resampling to 48khz...
Reducing depth from 64 to 32 bits...
Writing WAVs...
Creating file "dm.R.wav"...
Creating file "dm.C.wav"...
Creating file "dm.LFE.wav"...
Creating file "dm.SL.wav"...
Creating file "dm.SR.wav"...
Creating file "dm.L.wav"...
Clipping detected, a 2nd pass will be necessary. <WARNING>
The original audio track has a constant bit depth of 24 bits.
The processed audio track has a constant bit depth of 32 bits.
Starting 2nd pass...
Extracting TrueHD stream...
Removing TrueHD dialog normalization...
Decoding with libav/ffmpeg...
Resampling to 48khz...
Reducing depth from 64 to 32 bits...
Writing WAVs...
Creating file "dm.LFE.wav"...
Creating file "dm.SR.wav"...
Creating file "dm.L.wav"...
Creating file "dm.R.wav"...
Creating file "dm.C.wav"...
Creating file "dm.SL.wav"...
The processed audio track has a constant bit depth of 32 bits.
Encoding DTS <1536kbps> with Surcode...
Found Surcode DTS Encoder version 1.0.21.0.
Starting Surcode DTS Encoder failed. <ERROR>

Any ideas what can be wrong, and is there an option to have eac3to not remove the temporary .wav files, at least unless the DTS file creation is successful?

[tebasuna51]

For what you need a dts file if you have an ac3 640 kb/s?

Maybe you can make a flac, but with a -down24, the 64 or 32 bits product of resampling is enough.
Or a flac with 24/96.

BTW, maybe Surcode don't work with 32 bit float.

[TinTime]

I think it's using 32 bit int which should be ok for Surcode.

[jolson]

For what you need a dts file if you have an ac3 640 kb/s?
I don't yet have a "Media Extender" that can play TrueHD/DTS Master Audio (only HDI's Dune HD Center & BD Prime can do that) but I want to get the best quality I can play at the moment - which is 1,5Mbps DTS. So I convert to that from the Dolby TrueHD track.

I think my problem mentioned above was a firewall issue, eac3to didn't have permission to call Surcode but the dialogue wasn't modal so when I didn't see it and answer it disappeared after a while. When I reran the same command I got to answer yes to allow that call and all went through.

The created DTS track plays well in Foobar, but when I try to use tsMuxerGUI to mux together the vc1 track with the dts track the program complains "Can't detect stream type". Seems like Surcode doesn't leave a well-formed result...

But after running that DTS track through eac3to it becomes usable for tsNuxerGUI :)

[jamos]

(Seems TsMuxeR 1.9.1 still don't work with w64 files)

@madshi. Seems there are a bug in eac3to with w64 files like the recent with wav files.

This file, created by eac3to, is not recognized by eac3to. (work fine with other softs):

6x321.w64 (http://www.sendspace.com/file/h196ug)

tsmuxer 1.9.4 works with your file though..cheers no more need for pcm2tsmu

n/m got a error while muxing a big w64 file about 1/4 of the way through...not sure if its eac3to extract to w64 format or tsmuxer that is the problem.

[tebasuna51]

...but I want to get the best quality I can play at the moment - which is 1,5Mbps DTS. So I convert to that from the Dolby TrueHD track.

Yes, but I doubt than a dts 1536 Kb/s generated by Surcode is better than the core ac3 640 Kb/s.

[Blender]

Madshi,
I cannot get EAC3TO to write to 6tb raid arraywith 4k block size(to defeat>2tb limit in windows XP) .

Areca 1130 controller.

Is this a known issue? Is there a work around?

[73ChargerFan]

Yes, but I doubt than a dts 1536 Kb/s generated by Surcode is better than the core ac3 640 Kb/s.

It has better bass & rear separation. DTS has always been better than dolby digital.

[deathlord]

Madshi,
I cannot get EAC3TO to write to 6tb raid arraywith 4k block size(to defeat>2tb limit in windows XP) .

Areca 1130 controller.

Is this a known issue? Is there a work around?

Hm, I have no problems writing to such an array (highpoint controller).

[kurt]

It's probably not the best place to ask, but what am I supposed to do with 23,975 mkvs? I think they don't play stutterfree on Popcorn Hour and what I'm doing righ now is to demux all streams and mux it new with mkvmerge while changing fps in the container to 24000/1001 --> no judder on PCH. I guess changeto23.976 would lead to the same effect.

But what about the audio? is the difference neglectable? or should I use changeto23,976 to the audiostreams? is there a quality loss when changing fps to the DTS stream?

Edit:

I did some math:

2h movie = 7200s

0,001 frames difference for 1s --> 7,2 frames in total.

1s ---- 23,976 frames
xs ---- 7,2 frames

x = 0,300s = 300 ms

hm, 300 ms is quite a bit. Should be noticed at the end, I think 25-50 ms is noticable... I looked into some remuxed videos and didn't see such difference at the end of the movies....

Am I missing something? maybe mkvmerge did changing the fps for both, video and audio? (which would be great btw)

[tebasuna51]

It has better bass & rear separation. DTS has always been better than dolby digital.

Is your respectable opinion, but not the results of blind test.

Remember we are talking about the same source encoded with ac3 (supposed well encoded) and dts (Surcode).

Better bass and rear separation?
The bass never is a problem for a encoder.
The rear separation must be in the source.

[tbean]

When I test eac3to, the message regarding Nero Audio Decoder says:
"Nero Audio Decoder (Nero 7) is not working correctly
http://www.nero.com/eng/store-blu-ray.html"

When I try to access the link http://www.nero.com/eng/store-blu-ray.html, the page that comes up says nothing about the Nero Audio Decoder.

Can someone tell me the correct path to find the Nero Audio Decoder eac3to wants?

Thanks,
Tom

[TinTime]

Unfortunately the blu-ray / hd-dvd plugin is not available any more.

[ps3hacker]

Is your respectable opinion, but not the results of blind test.

A dts file created from surcode will most definitely sound better than a core ac3 file if the source is the same. Such as a lossless audio track, like true hd. Remember, there is no magic way the studios have to encode an ac3 file. The same could be said of dts. Surcode outputs the same dts file as a studio would(if not very, very, close)

[buzzqw]

@madshi

since eac3to (ffmpeg) is unable to decode correctly aac SBR and so want use nero decoder, would be possible to add support for Monogram AAC decoder (from radlight) ?
it's free/gpl

so, when aac sbr is to decode, check nero, else monogram, else ffmpeg

thanks

BHH

[jamos]

@madshi

I am having issues with w64 madshi. same as tabasuna51 is. also when I use a w64 in tsmuxer it will give a error after a minute or so. Roman tried a large w64 that he created then used tsmuxer and it works fine for him. He suggested it may be a header error. This only happens using DTS-ma converted to W64. true-hd to W64 does not give a error but the w64 file seems small.

link
http://forum.doom9.org/showthread.php?p=1272478#post1272478

[jamos]

If you're interested in why eac3to development has been slow recently, you may want to look here:

http://forum.doom9.org/showthread.php?t=146228

:D

very nice! love to see a GPU based renderer..:D

[jamos]

Is it correct to have a w64 file be less size than the original true-hd file?

thats what I am getting when I convert a true-hd file to w64 using eac3to. When I convert the true-hd file to pcm it is 7 gig. compared to the original 2 gig. true-hd file (which seems correct).

[ACrowley]

Mh, Strange.
eac3to gives Warnings on a lot of 23.976Fps 1080p x264 MKV/M2TS

M2TS, 1 video track, 2 audio tracks, 1:27:08, 24p /1.001
1: h264/AVC, 1920x800 23.976p (12:5)
2: DTS Hi-Res, German, 5.1 channels, 24 bits, 3018kbps, 48khz
(core: DTS, 5.1 channels, 24 bits, 1509kbps, 48khz)
3: DTS, English, 5.1 channels, 24 bits, 755kbps, 48khz
[v01] The video bitstream is encoded in a non-standard framerate. <WARNING>

But the Video is surely encoded in 23.976FPs (trough AVS with DGIndex/Decode). All other Tools/Palyser shows me correct 23.976Fps.

Whats wrong there?