eac3to - audio conversion tool

[madshi]

This forum has helped me out before so im back with more problems lol. I have a DDP audio file from EVODemux and when I run it through EAC3TO it does come up at the full time it should (that being 2hours23minutes) but yet when it converts it to WAV it is only coming out at 1hour6minutes long and yet the WAV file size is massive (6GB to be exact) I have never had this problem before and have tried numerous times now. Any suggestions anyone?
There are problems with WAV files above 2GB or 4GB. There's a "file size" field in the WAV file header which cannot hold more than 4GB. As a result this field "overflows" for too big WAV files. Some audio tools work around that by ignoring this header field if the WAV file is bigger than 2GB or 4GB. Others don't work around the problem. What you're seeing is most probably a WAV interpreter which doesn't handle the situation well. The WAV file is probably alright. It's just the tool or DirectShow filter which you're using which shows a wrong runtime.

[Sephiroth0000]

There are problems with WAV files above 2GB or 4GB. There's a "file size" field in the WAV file header which cannot hold more than 4GB. As a result this field "overflows" for too big WAV files. Some audio tools work around that by ignoring this header field if the WAV file is bigger than 2GB or 4GB. Others don't work around the problem. What you're seeing is most probably a WAV interpreter which doesn't handle the situation well. The WAV file is probably alright. It's just the tool or DirectShow filter which you're using which shows a wrong runtime.

MADSHI as always you are the man of wisodm but I have played the file and it only does let me play the 1 hour and 6 minutes worth of audio. Aftet that the file finishes. Are you saying when I actually apply it to the video it will be ok? How do I correct this problem?

[tebasuna51]

These wav's >4 GB can be encoded to ac3 with Aften (need the parameter: -readtoeof 1) or to aac with NeroAacEnc (parameter: -ignorelength).

You can also split in monowav's with WaveWizard and use others commercial encoders than accept monowav's.

[Sephiroth0000]

These wav's >4 GB can be encoded to ac3 with Aften (need the parameter: -readtoeof 1) or to aac with NeroAacEnc (parameter: -ignorelength).

You can also split in monowav's with WaveWizard and use others commercial encoders than accept monowav's.

Ironically enough that is what I am trying to do (making the WAV into AC3) however I am not sure on how to do it. I mean normally I do my HD DVD's into WMV with 5.1 which is easy but beyond that I do not really know a great deal. Could you go into more detail for me at all please? I do appreciate it :)

[madshi]

Ironically enough that is what I am trying to do (making the WAV into AC3)
Then why did you ask eac3to to give you a WAV file in the first place? Just use "eac3to source.ddp dest.ac3" and you're done.

[Sephiroth0000]

Then why did you ask eac3to to give you a WAV file in the first place? Just use "eac3to source.ddp dest.ac3" and you're done.

I did not ask it to make me a WAV file. I gave it the input file (ddp file) with an output file beaing a ac3 extensions and it comes up with some error about AC3 failing for some reason (not at computer so cannot state) but a WAV file was created successfully. I normally only have ever done WAV files before but this is stumping me bigtime. With regards to that command you put in your quote how would I put that in the GUI of your EAC3TO?

[DVDCake]

New at this, I'm getting "Getting Dump instance failure" after the temp file is created.

Any suggestions?

~DC

[Chumbo]

New at this, I'm getting "Getting Dump instance failure" after the temp file is created.

Any suggestions?

~DC
Did you bother to use the Search? I think this question's been asked a hundred times on this forum.

[Chumbo]

...With regards to that command you put in your quote how would I put that in the GUI of your EAC3TO?
OMG, I hope you're kidding...

[Sephiroth0000]

New at this, I'm getting "Getting Dump instance failure" after the temp file is created.

Any suggestions?

~DC

You are going to have to install the DUMP.AX filter in your Windows SYSTEM32 folder and then register it via COMMAND PROMPT with the regsvr32 command (please note that should you be running Windows Vista please run COMMAND PROMPT as Administrator) You can get the dump.ax filter with the program GRAPHEDIT which is a free download.

[Sephiroth0000]

OMG, I hope you're kidding...


I wish I was Chumbo but unfortunately not. I am still new to this and was only successful with doing EVO to WMV with 5.1 because of some of the geniuses and their input from this exact thread for who I thankyou very much (Afterwards I wrote up the guide and made it simplier covering every problem I had when attepting EVO to WMV HD with 5.1). Im not going to pretend to be a mastermind with this as im not. I am making everything I do available to everyone else so should anyone else get stuck they won't be anymore.

The more we all share our information the faster we move along as a whole.

[Chumbo]

I wish I was Chumbo but unfortunately not. I am still new to this and was only successful with doing EVO to WMV with 5.1 because of some of the geniuses and their input from this exact thread for who I thankyou very much (Afterwards I wrote up the guide and made it simplier covering every problem I had when attepting EVO to WMV HD with 5.1). Im not going to pretend to be a mastermind with this as im not. I am making everything I do available to everyone else so should anyone else get stuck they won't be anymore.

The more we all share our information the faster we move along as a whole.
Did you note what part I was responding to? If you use eac3togui, all you have to do is open the file and voila! It even shows you the command line it constructs. That's why I only included that part of the quote. Otherwise, what GUI are you talking about?

Thanks for your contributions. :)

[madshi]

I did not ask it to make me a WAV file. I gave it the input file (ddp file) with an output file beaing a ac3 extensions and it comes up with some error about AC3 failing for some reason (not at computer so cannot state)
Then please post the error text here so we can find out why AC3 encoding failed.

[Thunderbolt8]

is it normal that eac3to sometimes cant detect the bitdepth of a pcm track and therefore we need to put "-24" there manually? or is this considered to be a bug?

[ACrowley]

is it normal that eac3to sometimes cant detect the bitdepth of a pcm track and therefore we need to put "-24" there manually? or is this considered to be a bug?

tell eac3to the Bitdepth manuall and youve no Problmes

I Think Madshi can tell you why

[madshi]

is it normal that eac3to sometimes cant detect the bitdepth of a pcm track and therefore we need to put "-24" there manually? or is this considered to be a bug?
It is kind of normal. The current implementation just guesses with a rather simple algorithm. The algorithm only succeeds if it's really sure which bitdepth is the correct one to avoid a false classification.

The next eac3to version will have a much more sophisticated guessing algorithm. It will not only be able to detect 8bit, 16bit and 24bit bitdepths reliably, but it will also automatically detect number of channels (anything between 1 - 8) and big/little endian. It will even detect if the PCM/RAW file is really PCM/RAW or not.

Oooops, there goes my plan to not reveal any details about the next eac3to version yet... :eek: Fortunately there are still some improvements in store that I haven't mentioned yet... ;)

[Thunderbolt8]

tell eac3to the Bitdepth manuall and youve no Problmes

I Think Madshi can tell you why
I already did that of course, I just wanted to know if this happening is considered to be normal in the current version and whether he might need a sample from that file :P

[honai]

The next eac3to version will have a much more sophisticated guessing algorithm. It will not only be able to detect 8bit, 16bit and 24bit bitdepths reliably, but it will also automatically detect number of channels (anything between 1 - 8) and big/little endian. It will even detect if the PCM/RAW file is really PCM/RAW or not.

Oooops, there goes my plan to not reveal any details about the next eac3to version yet... Fortunately there are still some improvements in store that I haven't mentioned yet...

That and the previous announcements sound like quite a large feature set. Have you considered putting up a donation link to support your work? I'd be more than happy to do it.

[madshi]

That and the previous announcements sound like quite a large feature set. Have you considered putting up a donation link to support your work? I'd be more than happy to do it.
Thanks, I'll consider it... :D

[madshi]

Good news: Found the reason why the TrueHD decoded files often need a delay. The problem should be fixed in the next eac3to version.

[nautilus7]

YEAAAAAAAAAAAAAAAAAAAAAH

:eek::eek::eek::eek::eek::eek::eek::eek::eek::eek::eek::eek::eek:

Very good news indeed!

[Thunderbolt8]

Good news: Found the reason why the TrueHD decoded files often need a delay. The problem should be fixed in the next eac3to version.
this is really great. :thanks:
ive saved the original trueHD tracks in rebuilt .evos from the movies I remuxed & converted the sound to flac. can you already tell if I demux the TrueHD track again from that .evo and then use the new eac3to version (when its done), then the delay issue will be fixed automatically? or would I need the complete evos which include both, original audio and video, for that?

[madshi]

this is really great. :thanks:
ive saved the original trueHD tracks in rebuilt .evos from the movies I remuxed & converted the sound to flac. can you already tell if I demux the TrueHD track again from that .evo and then use the new eac3to version (when its done), then the delay issue will be fixed automatically? or would I need the complete evos which include both, original audio and video, for that?
It's how I explained earlier: If the first timestamps of the audio and video tracks are identical, you should not need any delay, but audio sync should be perfect automatically. Basically with the next eac3to version TrueHD files should behave the same way as E-AC3 files do with the current version. If however you have some movies where the first timestamp of the TrueHD track differs from the first timestamp of the video track, you will need to apply a delay. This delay can be directly seen in EvoDemux. I think the majority of the HD DVD movies will probably need no delay at all. But there are some movies which do need a delay. EvoDemux should tell us that.

[Thunderbolt8]

darn, should have saved the timestamp infos, too :P

[shambles]

maybe this should be in the madflac thread as it could just be a madflac bug but..

i converted a 7.1 blu-ray lpcm track to 7.1 flac. when playing it with madflac with the 'limit to 5.1' option on, the bl/br channels are used instead of sl/sr. when converting the 8ch blu-ray pcm to 8ch wave or flac, the channel order used seems to be l,r,c,lfe,bl,br,sl,sr. using -down6 results in sl/sr being used correctly.

is it eac3to mapping the channels wrong or madflac using/scrapping the wrong channels?

[madshi]

maybe this should be in the madflac thread as it could just be a madflac bug but..

i converted a 7.1 blu-ray lpcm track to 7.1 flac. when playing it with madflac with the 'limit to 5.1' option on, the bl/br channels are used instead of sl/sr. when converting the 8ch blu-ray pcm to 8ch wave or flac, the channel order used seems to be l,r,c,lfe,bl,br,sl,sr. using -down6 results in sl/sr being used correctly.

is it eac3to mapping the channels wrong or madflac using/scrapping the wrong channels?
Good catch! It's a bug in madFlac. Will be fixed with the next build.

[shambles]

holy fast reply, batman!

looking forward to new builds of both madflac and eac3to then :D

if i could request a feature for eac3to, i'd love to be able to specify 2 (or more) input files and have eac3to join them while decoding/converting. it's a pain in the ass with blu-ray having the movie spread over several m2ts's..

if you could just do 'eac3to input1.pcm+input2.pcm output.flac', it'd make the whole process much more pleasant ;)

[madshi]

if i could request a feature for eac3to, i'd love to be able to specify 2 (or more) input files and have eac3to join them while decoding/converting. it's a pain in the ass with blu-ray having the movie spread over several m2ts's..

if you could just do 'eac3to input1.pcm+input2.pcm output.flac', it'd make the whole process much more pleasant ;)
Hmmmm... I'm not 100% sure if simply joining the audio files is the mathematically correct way to handle this. I'm not sure how m2ts files are joined technically. I think simple joining would do for HD DVD audio. But I'm not sure about Blu-Ray. Probably it would work, but maybe someone with more m2ts knowledge can confirm?

[Inventive Software]

holy fast reply, batman!

looking forward to new builds of both madflac and eac3to then :D

if i could request a feature for eac3to, i'd love to be able to specify 2 (or more) input files and have eac3to join them while decoding/converting. it's a pain in the ass with blu-ray having the movie spread over several m2ts's..

if you could just do 'eac3to input1.pcm+input2.pcm output.flac', it'd make the whole process much more pleasant ;)

I believe that simply joining the TS files will suffice, from what I've read.

[Thunderbolt8]

when I understand it correctly the way the trueHD delay issue in cases where there shouldnt be any due to correct timestamps will be fixed only for the flac files, because eac3to will correct that problem, right? what about the demuxed trueHD tracks then, they will remain with this issue? wouldnt it be possible to talk with pelican and maybe try to implement it in evodemux, so that both, the normal trueHD tracks and the resulting flac tracks, will be fine?

[shambles]

I believe that simply joining the TS files will suffice, from what I've read.

but joining them takes a lot of time and disc space.. implementing the correct way to join the audio tracks to eac3to would make working with blu-ray audio so much easier.

[madshi]

when I understand it correctly the way the trueHD delay issue in cases where there shouldnt be any due to correct timestamps will be fixed only for the flac files, because eac3to will correct that problem, right? what about the demuxed trueHD tracks then, they will remain with this issue? wouldnt it be possible to talk with pelican and maybe try to implement it in evodemux, so that both, the normal trueHD tracks and the resulting flac tracks, will be fine?
There never was a problem with the demuxed TrueHD files. The problem was in how eac3to muxed those TrueHD files into a temporary EVO container. So no need to change anything in EvoDemux.

[madshi]

but joining them takes a lot of time and disc space.. implementing the correct way to join the audio tracks to eac3to would make working with blu-ray audio so much easier.
Well, I guess I could add an audio join feature. If it doesn't work then it doesn't work. But maybe it does.

[Thunderbolt8]

There never was a problem with the demuxed TrueHD files. The problem was in how eac3to muxed those TrueHD files into a temporary EVO container. So no need to change anything in EvoDemux.
oh. so you say that basically all demuxed trueHD tracks (with same video & audio starting pts) are fine and only the conversion to flac with current eac3to versions caused that problem?

[madshi]

oh. so you say that basically all demuxed trueHD tracks (with same video & audio starting pts) are fine and only the conversion [...] with current eac3to versions caused that problem?
Yes.

only the conversion to flac with current eac3to versions caused that problem?
The problem has nothing to do with FLAC. The bug is in eac3to's decoding of TrueHD. If you do "TrueHD -> AC3" with the current eac3to version, you'll have the same delay problems you're having with "TrueHD -> FLAC".

[nautilus7]

Just curious... Can you explain what was wrong with the remuxed .evo that cause the delay problem (if it's not too complicated to explain)?

[honai]

Probably just that the offset of the source EVO was not applied to the temp EVO that eac3to created when removing Dial.Norm.

[madshi]

eac3to searched for the first occurrence of a TrueHD header in the TrueHD stream and removed all bytes before the first header. I thought those bytes were garbage. But now I found out that if I don't remove those bytes, the decoded audio data is longer. Tested it with one sample TrueHD file. Got additional 106ms worth of audio data in the beginning of the file. I don't fully understand what those "garbage" bytes are for, but in the end it doesn't really matter. If I stop deleting those bytes, the delay problems should be gone.

[nautilus7]

I see. Thanks.

[killa_kid]

eac3to searched for the first occurrence of a TrueHD header in the TrueHD stream and removed all bytes before the first header. I thought those bytes were garbage. But now I found out that if I don't remove those bytes, the decoded audio data is longer. Tested it with one sample TrueHD file. Got additional 106ms worth of audio data in the beginning of the file. I don't fully understand what those "garbage" bytes are for, but in the end it doesn't really matter. If I stop deleting those bytes, the delay problems should be gone.

i just ripped The Departed from HD DVD which has TrueHD audio and it was approx 100ms out of sync, so I'm guessing its true or most files. Batman Begins didn't seem to have much of a problem though. I am currently doing Blood Diamond and lets see if it happens this time.

And thanks madshi, the tool is fantastic and we'd all be screwed without it!

[honai]

so I'm guessing its true or most files

You are guessing wrong.

[Murleen]

eac3to searched for the first occurrence of a TrueHD header in the TrueHD stream and removed all bytes before the first header. I thought those bytes were garbage. But now I found out that if I don't remove those bytes, the decoded audio data is longer. Tested it with one sample TrueHD file. Got additional 106ms worth of audio data in the beginning of the file. I don't fully understand what those "garbage" bytes are for, but in the end it doesn't really matter. If I stop deleting those bytes, the delay problems should be gone.

How many bytes were you seeing before the F8726FBA sync word?

[killa_kid]

You are guessing wrong.

I mistyped that, I meant to say some files, not most.

[madshi]

How many bytes were you seeing before the F8726FBA sync word?
That differs between tracks. However, it seems that the 4 bytes directly before the sync dword are important (for whatever reason). If I remove only those 4 bytes, I'm already losing about 100ms worth of audio data. Seemingly the audio decoder wants to have those 4 bytes and skips the whole frame if those bytes are not there. I'm not sure, maybe those 4 bytes in front of the sync dword are all that was missing. But sometimes there's more "garbage" (or not garbage) in front of the first sync dword. Not sure whether those bytes have any meaning. Maybe, maybe not...

[Thunderbolt8]

could there actually be a problem in the future, when I remove dialnorm from eac3 tracks, which I intend to use further? what I mean is could something happen like for example that some hardware decoders would try to remove it at playback, but since its already removed, it would result in errors, or wouldnt play at all or some other loss of quality? so would it be best to keep that track 100% in its original state or could the removal of dialnorm via eac3to not harm the tracks quality at all somehow?


btw. are dialnorm and DRC actually also applied for normal AC3 and DTS tracks (not eac3 and DTS-HD) from DVDs (DRC was restricted to dolby only?) ? if yes, is it actually possible then also to improve all those normal DVD audio tracks and get rid of those 2 things by converting these tracks to FLAC ?

[honai]

could there actually be a problem in the future, when I remove dialnorm from eac3 tracks, which I intend to use further?

I admire your ability to invent problems and post fictitous scenarios in this thread.

what I mean is could something happen like for example that some hardware decoders would try to remove it at playback, but since its already removed, it would result in errors, or wouldnt play at all or some other loss of quality?

Answer: No.

[madshi]

could there actually be a problem in the future, when I remove dialnorm from eac3 tracks, which I intend to use further? what I mean is could something happen like for example that some hardware decoders would try to remove it at playback, but since its already removed, it would result in errors, or wouldnt play at all or some other loss of quality? so would it be best to keep that track 100% in its original state or could the removal of dialnorm via eac3to not harm the tracks quality at all somehow?
The studio can decide which dialnorm value to use. It's perfectly legit for a studio to encode an (E)-AC3 or TrueHD track with dialnorm set to "off". So no decoder can possible stumble over such tracks. Removing dialnorm does not harm audio quality any bit. Not now and not in the future. So there's no need to keep the original track. The only thing you'll lose by removing dialnorm is ... the dialnorm feature.

Btw, Sony has dialnorm turned off on all their newer Blu-Ray discs.

btw. are dialnorm and DRC actually also applied for normal AC3 and DTS tracks (not eac3 and DTS-HD) from DVDs (DRC was restricted to dolby only?) ? if yes, is it actually possible then also to improve all those normal DVD audio tracks and get rid of those 2 things by converting these tracks to FLAC ?
AC3: Most tracks have dialnorm activated. The reference decoders (Nero, Sonic) apply both dialnorm and DRC on those tracks. AC3Filter applies neither. So when using AC3Filter you should be fine.
DTS: Most tracks do not have dialnorm activated. Having dialnorm "off" seems to be the default value in the DTS encoder. No decoder that I know applies DRC on DTS decoding - unless you specifically ask it to. So DTS seems to be rather problem free in this aspect.
TrueHD: Most tracks have dialnorm activated (with the exception of those coming from Sony). The reference decoders (Nero, Sonic) apply dialnorm on those tracks. Theoretically they should also apply DRC. But only Sonic does that. Nero doesn't - for whatever reason.

What I said above about E-AC3 dialnorm removal is also valid for all other formats: Turning dialnorm off doesn't harm audio quality in any way.

Converting AC3 tracks to FLAC to avoid DRC and dialnorm is surely possible. But if you playback through the PC, you don't really need to do that. Just use AC3Filter and you're done. Of course AC3Filter doesn't use the Dolby reference AC3 decoder code, though. So it's possible that maybe the reference decoders could have slightly better audio quality (don't know). But when using the reference decoders we're back with at least DRC.

[nautilus7]

I am trying to convert an E-AC3 track (from Smokin Aces HD DVD) to AC3, but i get the following error message. What does it mean?

C:\Tools>eac3to aces.eac3 aces.ac3
E-AC3, 5.1 channels, 1:48:56, 1536kbit/s, 48khz, dialnorm: -27dB
Remove Dialog Normalization information. Please wait...
This track is not clean. Processing aborted.
Please clean the track with delaycut and then retry eac3to.

EDIT: I run delaycut in ignore mode. Here's the log:

====== INPUT FILE INFO ========================
File is eac3
Bitrate (kbit/s) 1536
Act rate (kbit/s) 1536.000
File size (bytes) 1254904832
Channels mode 3/2: L+C+R+SL+SR
Sampling Frec 48000
Low Frec Effects LFE: Present
Duration 01:48:55.962
Frame length (ms) 5.333333
Frames/second 187.500000
Num of frames 1225493
Bytes per Frame 1024.0000
Size % Framesize 0
CRC present: YES
=============================================
====== TARGET FILE INFO ======================
Start Frame 0
End Frame 1225492
Num of Frames 1225493
Duration 01:48:55.962
NotFixedDelay 0.0000
=============================================
====== PROCESSING LOG ======================
Time 00:20:39.722; Frame#= 232449. Unsynchronized frame...SKIPPED 1024 bytes. Found new synch word
Time 01:06:05.269; Frame#= 743489. Unsynchronized frame...SKIPPED 1024 bytes. Found new synch word

[honai]

Probably CRC errors. Delaycut has an option to fix those.

[Murleen]

That differs between tracks. However, it seems that the 4 bytes directly before the sync dword are important (for whatever reason). If I remove only those 4 bytes, I'm already losing about 100ms worth of audio data. Seemingly the audio decoder wants to have those 4 bytes and skips the whole frame if those bytes are not there. I'm not sure, maybe those 4 bytes in front of the sync dword are all that was missing. But sometimes there's more "garbage" (or not garbage) in front of the first sync dword. Not sure whether those bytes have any meaning. Maybe, maybe not...

The 4 bytes beforehand are actually part of the same frame - the first two bytes indicate the frame length, the next two are a form of DTS - these are then followed by the sync word. Without the bytes, 128 packets of 40 samples will be dropped - about 107ms by my reckoning.

If you've got any samples with extra junk on the front I'd like to get a look at them - PM me if that's possible.