eac3to - audio conversion tool

[madshi]

I did not even know I was supposed to install anything else. What else am I supposed to get to make it work?
See first post of this thread. Surcode is a commercial software and must be bought and installed for DTS encoding to work. If you don't want to spend money, you can use AC3 encoding instead.

[Sephiroth0000]

See first post of this thread. Surcode is a commercial software and must be bought and installed for DTS encoding to work. If you don't want to spend money, you can use AC3 encoding instead.

I went to their website and there are loads of different products. Which one do I actually need Madshi? (please not the expensive ones lol)

[menlvd]

thnx madshi for great tool and good apply/reverse PAL speedup
maybe U can do in future ver with output multimono waves :)

[madshi]

I went to their website and there are loads of different products. Which one do I actually need Madshi? (please not the expensive ones lol)
Again read the first post in this thread. The product name is listed there. And unfortunately it *is* an expensive one.

[madshi]

thnx madshi for great tool and good apply/reverse PAL speedup
maybe U can do in future ver with output multimono waves :)
What do you mean with multimono waves? You mean 6 mono wav files? That's already supported! Just do "eac3to sourceFile dest.wavs".

[menlvd]

What do you mean with multimono waves? You mean 6 mono wav files? That's already supported! Just do "eac3to sourceFile dest.wavs".

thx my mistake
and how about an a percentage progress bar of job
such as a completed xx%

[madshi]

eac3to v2.01 released

http://madshi.net/eac3to.zip

* fixed: AC3 encoding sometimes crashed when being fed 24 bit audio data
* fixed: AC3 encoded files were invalid when being fed 24 bit audio data
* eac3toGUI didn't work with eac3to v2.0
* "eac3to source.ac3 dest.ac3 -slowdown" didn't do anything useful
* when a crash occurs, the bug report is automatically copied to clipboard now
* some minor cosmetic improvements

[madshi]

thx my mistake
and how about an a percentage progress bar of job
such as a completed xx%
There is already a progress bar. It's not with %, but the conversion is fully done when the progress bar reaches the right side of the window.

[madshi]

did another remux try, the first attempt was only with copy /b and then xport use. did now run tsremux over the with copy /b merged .m2ts before using xport, but the result was the same: audio still out of sync in the big .mkv during the movie (flac with v1.23) and the FLAC file created with v20 still cant be put into .mka, again parsing error direct at the beginning. might really be a little bug of the new version :P
Can't reproduce the problem here. Your samples you sent me can be put into mka just fine. Does putting them into mka really fail for you?

Again: Please test the external standalone v20 created FLAC file with madFlac. Does that play properly?

I think I found a bug in mkvtoolnix. Just converted (as a test) Pirates of the Caribbean 24bit PCM to FLAC and tried to mux that into mkvtoolnix. mkvtoolnix claimed conversion was done ok, but the output file was only 5MB big! I think mkvtoolnix stumbled over the FLAC file size (> 2GB) or maybe about the number of samples (> 4GB). Don't know...

[shambles]

did the new version break eac3 decoding? i get a crash if dtsac3source is not registered when i run eac3to and this if it is:

E:\Program Files\eac3to>eac3to 00.eac3 00.wav
E-AC3, 5.1 channels, 1:39:57, 640kbit/s, 48khz, dialnorm: -27dB
Decoding with DirectShow (Nero Audio Decoder 2)...
Removing dialog normalization...
Loading DirectShow source file failed.

i tried un/re-registering dtsac3source and even reinstalling nero and re-registering the hddvd/bluray plugin, but none of that helped. i sent you the bug report via pm..

[Thunderbolt8]

Can't reproduce the problem here. Your samples you sent me can be put into mka just fine. Does putting them into mka really fail for you?

Again: Please test the external standalone v20 created FLAC file with madFlac. Does that play properly?

I think I found a bug in mkvtoolnix. Just converted (as a test) Pirates of the Caribbean 24bit PCM to FLAC and tried to mux that into mkvtoolnix. mkvtoolnix claimed conversion was done ok, but the output file was only 5MB big! I think mkvtoolnix stumbled over the FLAC file size (> 2GB) or maybe about the number of samples (> 4GB). Don't know...
I cant put that v2.0 24-bit flac file into .mka with mkvtoolnix, it gives a parsing error immediately, while its possible with the one created with version v.123

error msg:
mkvmerge v2.1.0 ('Another Place To Fall') built on Aug 19 2007 13:39:56
'...\rataCOPYB.flac': Using the FLAC demultiplexer.
+-> Parsing the FLAC file. This can take a LONG time.
+-> Pre-parsing FLAC file: 0%
+-> Pre-parsing FLAC file: 100%
'...\rataCOPYB.flac' track 0: Using the FLAC output module.
The file '...\rataCOPYB.mka' has been opened for writing.
The cue entries (the index) are being written...
Muxing took 0 seconds.

[Mtz]

eac3to v2.01 released

This version solved my previous problems and the GUI is working too. Thank you, madshi.
Regarding new names I think madconverter from that list si the best.
Regarding GUI: at destination file tab, after pressing Browse to inculde the dts extension, and Save button instead of Open. Will be nice at the "Conversions Options" tab to have checkboxes for all formats which can be saved by eac3to, the "DTS Rate" to be just "Rate" because of checkboxes.
Also more settings like "keep intermediate files" or "Temporary folder".

enjoy,
Mtz

[nautilus7]

From the 1st post: -quality=4 slowdown/speedup/resampling quality (0 = low; 4 = very high)

What is the default value if not used?
What does it mean/do or how it works?
How does it affect the processing time?

[nautilus7]

The -slowdown "thing" seems to work, but i just want to clarify something: input.ac3 output.ac3 -slowdown doesn't leave the bitrate same as the input but re-encodes the new ac3 in 640 kbps, right?

[madshi]

I cant put that v2.0 24-bit flac file into .mka with mkvtoolnix, it gives a parsing error immediately, while its possible with the one created with version v.123

error msg:
mkvmerge v2.1.0 ('Another Place To Fall') built on Aug 19 2007 13:39:56
'...\rataCOPYB.flac': Using the FLAC demultiplexer.
+-> Parsing the FLAC file. This can take a LONG time.
+-> Pre-parsing FLAC file: 0%
+-> Pre-parsing FLAC file: 100%
'...\rataCOPYB.flac' track 0: Using the FLAC output module.
The file '...\rataCOPYB.mka' has been opened for writing.
The cue entries (the index) are being written...
Muxing took 0 seconds.
Does mkvtoolnix really say that an error occurred? Where does it say that? I have the same result you're having (log looks the same), but for me mkvtoolnix claims everything is fine. Obviously not everything is fine because the resulting mka file is much too short. But mkvtoolnix believes everything would be fine. Is it the same for you?

And now I'm asking you for the 3rd time: Does the external standalone FLAC file play fine with madFlac? If you want me to fix the problem, it would help a lot if you could answer the questions I'm asking you. Thanks...

[madshi]

did the new version break eac3 decoding? i get a crash if dtsac3source is not registered when i run eac3to and this if it is:

E:\Program Files\eac3to>eac3to 00.eac3 00.wav
E-AC3, 5.1 channels, 1:39:57, 640kbit/s, 48khz, dialnorm: -27dB
Decoding with DirectShow (Nero Audio Decoder 2)...
Removing dialog normalization...
Loading DirectShow source file failed.

i tried un/re-registering dtsac3source and even reinstalling nero and re-registering the hddvd/bluray plugin, but none of that helped. i sent you the bug report via pm..
Thanks for the report. eac3to tried to automatically register the dtsac3source filter if it isn't registered yet. There was a bug in this automatic registering which made eac3to crash. This is fixed in v2.02. However, I don't really understand why manually registering dtsac3source didn't help. It should have helped. And it did in my test. Anyway, the crash should be fixed now.

[madshi]

From the 1st post: -quality=4 slowdown/speedup/resampling quality (0 = low; 4 = very high)

What is the default value if not used?
What does it mean/do or how it works?
How does it affect the processing time?
The default value is "4" (highest quality). The higher the quality the higher the processing time, of course. I wouldn't recommend to go lower than quality "2". Actually I recommend to keep using "4". I think it's better to wait a few seconds longer than having to live forever with a lower than possible audio quality... :)

The -slowdown "thing" seems to work, but i just want to clarify something: input.ac3 output.ac3 -slowdown doesn't leave the bitrate same as the input but re-encodes the new ac3 in 640 kbps, right?
Yes. eac3to always uses 640kbps encoding for multichannel tracks by default, regardless of which bitrate the source file had. This is as intended/designed and I won't change that. If you want to encode with lower bitrate, you can manually tell eac3to to do that.

[madshi]

eac3to v2.02 released

http://madshi.net/eac3to.zip

* fixed: automatic registering of the dtsac3source filter crashed

[Sephiroth0000]

Madshi I have made DTS, AVI, WAV and DDP audio files yet Nero Recode 2 does not register any of them at all and will not let me add them (it does the video just fine) but not the audio....any suggestions please?

[madshi]

Madshi I have made DTS, AVI, WAV and DDP audio files yet Nero Recode 2 does not register any of them at all and will not let me add them (it does the video just fine) but not the audio....any suggestions please?
I've never used Nero Recode yet, so I can't really help you there. Is this problem in any way related to eac3to?

[Sephiroth0000]

I've never used Nero Recode yet, so I can't really help you there. Is this problem in any way related to eac3to?

No not really EAC3TO works extremely well and seems to run faster actually on my system. I just thought you would have a heads up doing all this audio and stuff....no problem

[shambles]

no crash now but i'm still getting "Loading DirectShow source file failed." :confused:

dtsac3source -> nero audio decoder 2 works fine in graphedit (renamed to recode.exe obviously)

[madshi]

no crash now but i'm still getting "Loading DirectShow source file failed." :confused:
Which OS is that? Did that work with eac3to v2.0? That would be strange because I've no done any changes in this area. Do you have more than just one eac3 test files? Do they all fail to work? Or is it just one?

[madshi]

I cant put that v2.0 24-bit flac file into .mka with mkvtoolnix, it gives a parsing error immediately, while its possible with the one created with version v.123

error msg:
mkvmerge v2.1.0 ('Another Place To Fall') built on Aug 19 2007 13:39:56
'...\rataCOPYB.flac': Using the FLAC demultiplexer.
+-> Parsing the FLAC file. This can take a LONG time.
+-> Pre-parsing FLAC file: 0%
+-> Pre-parsing FLAC file: 100%
'...\rataCOPYB.flac' track 0: Using the FLAC output module.
The file '...\rataCOPYB.mka' has been opened for writing.
The cue entries (the index) are being written...
Muxing took 0 seconds.
I've found out that this is a bug in mkvtoolnix. mkvtoolnix doesn't seem to like *any* FLAC files created by FLAC v1.2.1. But FLAC files created by FLAC v1.2.0 (which eac3to v1.23 used) work fine with mkvtoolnix. I'll contact Mosu and ask for a fix. In the meanwhile I've reverted back to FLAC v1.2.0. You can redownload the latest eac3to build:

http://madshi.net/eac3to.zip

I didn't change eac3to, I just swapped the libFLAC.dll with on older version. This fixed the mkvtoolnix problem for me.

[shambles]

xp sp2, didn't work in 2.0, all eac3 tracks fail to work..

they work just fine in 1.23 though.

[Thunderbolt8]

will give it a try

[shambles]

also the source1+source2 input is broken atleast with the 7.1 blu-ray pcm track i have, it's fine until the join point but from then on the channels are mapped wrong (same problem i had when trying to join the files by copy /b blah1+blah2 blah)

[madshi]

xp sp2, didn't work in 2.0, all eac3 tracks fail to work..

they work just fine in 1.23 though.
xpsp2 here, too.

That's kind of strange. Do eac3to tracks still work with 1.23 right now? I mean if you start 2.02 eac3 conversion fails. And if you start 1.23 right next, it works? Please try 1.23 with the "-orbitlee" switch because that is comparable to what 2.02 is doing internally. Thanks...

[madshi]

also the source1+source2 input is broken atleast with the 7.1 blu-ray pcm track i have, it's fine until the join point but from then on the channels are mapped wrong (same problem i had when trying to join the files by copy /b blah1+blah2 blah)
There's nothing I can do here. If the channels are mapped wrong after the join point that means that there are a few bytes too much or too few at the join point. It's nearly impossible for eac3to to know/detect that.

Are you demuxing with xport or with TsRemux? Have you tried running TsRemux over the joined TS file? Does that fix the problem?

[honai]

Wow. That's a huge improvement, thanks a lot for your work and dedication! Now I won't ever have to use any other tool for all my audio needs.

madEierlegendeWollmilchsau might be worth pondering (Germans are known for cranky names anyway). ;)

I'm wondering - how did you avoid having to create temp files? Do you use junction points?

[shambles]

xpsp2 here, too.

That's kind of strange. Do eac3to tracks still work with 1.23 right now? I mean if you start 2.02 eac3 conversion fails. And if you start 1.23 right next, it works? Please try 1.23 with the "-orbitlee" switch because that is comparable to what 2.02 is doing internally. Thanks...

yes, 1.23 still works now. and it does work with -orbitlee too

There's nothing I can do here. If the channels are mapped wrong after the join point that means that there are a few bytes too much or too few at the join point. It's nearly impossible for eac3to to know/detect that.

Are you demuxing with xport or with TsRemux? Have you tried running TsRemux over the joined TS file? Does that fix the problem?

demuxing with xport. and i mean i had the channel mapping problem when i tried to join the demuxed pcm files. the mapping is fine when joining the ts files

[madshi]

madEierlegendeWollmilchsau might be worth pondering
:D

I'm wondering - how did you avoid having to create temp files? Do you use junction points?
Not sure what you mean with "junction points". eac3to v2 internally is built somewhat similiar to how DirectShow works. There are decoder "modules", encoder modules and processing modules. They pass data from one to another in RAM. So no temp files need to be stored. There were a few problems:

(1) I had to replace the well known "Dump" filter with my own real DirectShow filter which grabs the DirectShow output. Of course instead of dumping the output to a file (that's what the original dump filter does) my custom dump filter passes the data directly to me in RAM. Furthermore my dump filter tells me which data format the data has (how many channels etc). The original dump filter didn't store this information so the old eac3to version had to guess.
(2) I'm hooking the file read accesses of the DirectShow source filters (e.g. DTS/DD+/AC3 source). Instead of reading a real file I'm simulating a virtual file. This way I can feed data to the DirectShow source filters via RAM and don't need to create a temp file. This hooking is a bit hacky, so I'm a bit afraid that it might make some problems, but so far it seems to work well.

The only situation where I need to create temp files now is for Surcode encoding. Surcode is another process so it'd be harder to hook file reading there. It might still be possible but I don't think that I'll invest the time for that.

[madshi]

yes, 1.23 still works now. and it does work with -orbitlee too
Hmmmm... Does AC3 and DTS decoding work with eac3to 2.0x? Is it just E-AC3 decoding which fails? Or does AC3 and DTS decoding also fail?

demuxing with xport. and i mean i had the channel mapping problem when i tried to join the demuxed pcm files. the mapping is fine when joining the ts files
Too bad. I don't think I can work around that. You could ask the xport author if he could correct it. He might not be able to demux perfectly the same way as if you joined the TS files first. But at least it should be possible for him to demux in that way that the channel mapping stays correct.

[shambles]

Hmmmm... Does AC3 and DTS decoding work with eac3to 2.0x? Is it just E-AC3 decoding which fails? Or does AC3 and DTS decoding also fail?

ac3 and dts decoding also fail indeed


Too bad. I don't think I can work around that. You could ask the xport author if he could correct it. He might not be able to demux perfectly the same way as if you joined the TS files first. But at least it should be possible for him to demux in that way that the channel mapping stays correct.

well, there's nothing wrong with the channel mapping with the individual pcm files, it only gets screwed when they're joined..

[Thunderbolt8]

And now I'm asking you for the 3rd time: Does the external standalone FLAC file play fine with madFlac? If you want me to fix the problem, it would help a lot if you could answer the questions I'm asking you. Thanks...
should I still try that out, is it still needed ?
I already tried that, but the windows complains about the pathname thing, when I add /dubb + flacpath at the end of the commandline.

putting the flac into .mka worked now btw.

[madshi]

ac3 and dts decoding also fail indeed
Hmmmmmmmmm... That means that the DTS/DD+/AC3 source filter fails to work correctly with v2.0x on your PC. I'll have to think about a way how we can find out what's going wrong. Do you have another PC you can try this on? It seems that this seems to work for most other people. So I guess there must be something special about your PC...

well, there's nothing wrong with the channel mapping with the individual pcm files, it only gets screwed when they're joined..
Well, that's a good hint. It means that the demuxed audio data of the first part is a few bytes too long (or too short). Basically the size of each demuxed PCM file must be dividable through "channelno * bitdepth / 8". E.g. if you have a 24bit 6-channel movie and the file size of a PCM file is 18002 bytes long, there's something wrong. If you calculate "18002 / (channelno * 24 / 8) = 1000.111" you end up with a decimal number. This is the reason why the channel mapping is all wrong. You can manually fix that by reducing file size so that the file size is dividable correctly. E.g. if you reduce the file size in the above example to 18000 we get "18000 / (6 * 24 / 8) = 1000". This will correct the channel mapping problem.

xport should be able to do this automatically, but seemingly it doesn't. As I said before this is something the xport author could probably easily fix.

[madshi]

should I still try that out, is it still needed ?
It's not needed if eac3to v2.02 with libFlac 1.2.0 works perfectly fine for you. Then we can all be happy... :)

[nautilus7]

The default value is "4" (highest quality). The higher the quality the higher the processing time, of course. I wouldn't recommend to go lower than quality "2". Actually I recommend to keep using "4". I think it's better to wait a few seconds longer than having to live forever with a lower than possible audio quality... :)Yes, i agree. I like 4. :p


Yes. eac3to always uses 640kbps encoding for multichannel tracks by default, regardless of which bitrate the source file had. This is as intended/designed and I won't change that. If you want to encode with lower bitrate, you can manually tell eac3to to do that.I knew that 640 was the default bitrate, but i thought the -slowdown would produced a same bitrate track as the input file.

[Thunderbolt8]

Hmmmmmmmmm... That means that the DTS/DD+/AC3 source filter fails to work correctly with v2.0x on your PC. I'll have to think about a way how we can find out what's going wrong. Do you have another PC you can try this on? It seems that this seems to work for most other people. So I guess there must be something special about your PC...


Well, that's a good hint. It means that the demuxed audio data of the first part is a few bytes too long (or too short). Basically the size of each demuxed PCM file must be dividable through "channelno * bitdepth / 8". E.g. if you have a 24bit 6-channel movie and the file size of a PCM file is 18002 bytes long, there's something wrong. If you calculate "18002 / (channelno * 24 / 8) = 1000.111" you end up with a decimal number. This is the reason why the channel mapping is all wrong. You can manually fix that by reducing file size so that the file size is dividable correctly. E.g. if you reduce the file size in the above example to 18000 we get "18000 / (6 * 24 / 8) = 1000". This will correct the channel mapping problem.

xport should be able to do this automatically, but seemingly it doesn't. As I said before this is something the xport author could probably easily fix.
not sure if I understood this correctly now, but it basically means that demuxed audio tracks (by xport) from joined .m2ts tracks are not 100% in sync as they should?
maybe this also explains my problems with that seamless branching of ratatouille. no matter how I join the files (copy /b, tsremux, tssplitter), in the end the remuxed file (avc, flac) loses sync sooner or later.
and when I just try to play that joined .m2ts file with powerdvd then I dont have any sound at all :S

[madshi]

not sure if I understood this correctly now, but it basically means that demuxed audio tracks (by xport) from joined .m2ts tracks are not 100% in sync as they should?
If there's only one m2ts file then it should be in sync. Problems start when there are multiple m2ts files. I'm not sure if there's a problem with xport. Maybe some audio data is stored twice (in the end of part1.m2ts and in the beginning of part2.m2ts)? In that case xport can't really do much. There'd have to be a demuxer which looks at all m2ts files and demux the audio while taking into account the exact timestamps etc. Probably quite difficult to do.

[Thunderbolt8]

hm...:D
would it actually be much work to enhance the offsetpts function also to work on blu-ray .m2ts files? :P

[madshi]

ac3 and dts decoding also fail indeed
Can you please retry with v2.03? It will most likely still fail. But if you use the new "-debug" switch, eac3to will write a "log.txt" file. Can you please PM me that file? Thanks...

[madshi]

hm...:D
would it actually be much work to enhance the offsetpts function also to work on blu-ray .m2ts files? :P
It would just change the timestamps. I don't think it would improve the audio demuxing with xport. It would probably not have any effect on xport.

[madshi]

eac3to v2.03 released

http://madshi.net/eac3to.zip

* new "-debug" switch added

[Thunderbolt8]

It would just change the timestamps. I don't think it would improve the audio demuxing with xport. It would probably not have any effect on xport.
hm in how far are .m2ts files then different in this regard to .evo files? evodemux seems to handle them correctly after this change, but xport obviously somehow ignores this info?

[madshi]

hm in how far are .m2ts files then different in this regard to .evo files? evodemux seems to handle them correctly after this change, but xport obviously somehow ignores this info?
OffsetPTS has no effect whatsoever on demuxing audio tracks with EvoDemux. OffsetPTS helps only for joining EVO files. If all you're doing is demuxing audio with EvoDemux you'd never need OffsetPTS.

[shambles]

Well, that's a good hint. It means that the demuxed audio data of the first part is a few bytes too long (or too short). Basically the size of each demuxed PCM file must be dividable through "channelno * bitdepth / 8". E.g. if you have a 24bit 6-channel movie and the file size of a PCM file is 18002 bytes long, there's something wrong. If you calculate "18002 / (channelno * 24 / 8) = 1000.111" you end up with a decimal number. This is the reason why the channel mapping is all wrong. You can manually fix that by reducing file size so that the file size is dividable correctly. E.g. if you reduce the file size in the above example to 18000 we get "18000 / (6 * 24 / 8) = 1000". This will correct the channel mapping problem.

xport should be able to do this automatically, but seemingly it doesn't. As I said before this is something the xport author could probably easily fix.

demuxing the pcm files again now, will see what the filesizes are. if it is some bytes too long, how would i go about reducing the size?

Hmmmmmmmmm... That means that the DTS/DD+/AC3 source filter fails to work correctly with v2.0x on your PC. I'll have to think about a way how we can find out what's going wrong. Do you have another PC you can try this on? It seems that this seems to work for most other people. So I guess there must be something special about your PC...

it does indeed work on the other computer.. really strange.

Can you please retry with v2.03? It will most likely still fail. But if you use the new "-debug" switch, eac3to will write a "log.txt" file. Can you please PM me that file? Thanks...

yes it still fails but it doesn't seem to write log.txt with -debug

E:\Program Files\eac3to>eac3to 00.tmp.ddp 00.wav -debug
E-AC3, 5.1 channels, 1:39:57, 640kbit/s, 48khz
Decoding with DirectShow (Nero Audio Decoder 2)...
Loading DirectShow source file failed.

no log.txt in eac3to dir..

[shambles]

the pcm file from the first m2ts = 2 294 179 654 bytes

2294179654 / (8 * 16 / 8) = 143386228,375 so yes, indeed, therein lies our bug.

the file from the second m2ts is correctly dividable

[Thunderbolt8]

so xport is currently not recommended to use for joined .m2ts files?

are there other, more reliable demuxers at present?

[madshi]

yes it still fails but it doesn't seem to write log.txt with -debug

E:\Program Files\eac3to>eac3to 00.tmp.ddp 00.wav -debug
E-AC3, 5.1 channels, 1:39:57, 640kbit/s, 48khz
Decoding with DirectShow (Nero Audio Decoder 2)...
Loading DirectShow source file failed.

no log.txt in eac3to dir..
The log.txt is written to the "current" folder. The one where the command prompt is at. E.g. if the command prompt sais: "C:>" the log file it written to "C:\log.txt".