View Full Version : eac3to - audio conversion tool
Nico8583
5th February 2016, 21:56
Thank you, but I want to keep 5.1 so I don't want to downmix to stereo. So I forget DRC, I will keep AC3 without recode and I will recode DTS to AC3 with eac3to or ffmpeg ;)
Thank you for the advise ;)
.sk
6th February 2016, 16:28
Is it possible to losslessly merge mp3 files (same encoder and settings) with eac3to into one mp3 file?
Thunderbolt8
6th February 2016, 17:02
dunno, but maybe it already works with "copy file1.mp3+file2.mp3+file3.mp3..."
tebasuna51
6th February 2016, 19:57
If you do:
copy /B file1.mp3 + file2.mp3 output.mp3
- some tags at end of file1.mp3 are at the midle of output.mp3
- If are VBR, the duration of output.mp3 show only the duration of file1.mp3.
And some players can stop play at this duration.
You can use eac3to:
eac3to file1.mp3+file2.mp3 output.mp3
- the tags at end of file1.mp3 are skiped
- The problem with VBR duration still exist.
You can use Foobar2000 and right click over the mp3 -> Utilities -> Fix VBR MP3 header
r0lZ
7th February 2016, 11:15
MP3DirectCut can also losslessly join two MP3 files (if they have been encoded exactly in the same way of course). You will have to copy the whole content of file 2, and paste it at the end of file 1, then save the complete audio. No problem with the tags or duration. Only the replay gain info (if any) may be wrong. And BTW, with the Copy /B trick (and perhaps also with eac3to), another problem exists. The bad samples at the end of the first file and beginnong of the second file are not removed, and a short silence may be perceptible. With MP3DirectCut, you cannot copy that part of the file (if it has been created with a good encoder), and there is no problem.
There are several versions of the MP3DirectCut program. I use the old one, still available here (http://filehippo.com/download_mp3directcut/). The new version is here (http://mpesch3.de1.cc/mp3dc.html). I don't remember why I have preferred the old version.
BTW, I've tried to remove one channel from a stereo MP3 without re-encoding, but I haven't found a tool to do it. It's useful when a mono track has been encoded in stereo, to regain disc space and be more coherent with the source. The two channels contain exactly the same data (or, with joint stereo, the second channel should be almost empty). Someone knows a tool able to do that?
LigH
7th February 2016, 11:26
Efficient MP3 encoders use Joint Stereo for audio which has probably similar channels, and use adaptively the Mid/Side encoding (not encoding the left channel separately from the right channel, but instead their sum and their difference, because the difference is probably rather low in comparison to the sum and thus needs less bitrate). What has not been encoded separately, cannot be separated without recoding.
r0lZ
8th February 2016, 10:43
That makes sense. Thanks.
Stereodude
8th February 2016, 19:54
What is its utility with eac3to ? I never installed Haali Media Splitter.
My understanding is that it's necessary if you want to have eac3to write directly to a MKV container.
Stereodude
8th February 2016, 19:58
You could always pipe to QAAC. Something that still gets updates.
I found this to be very slow. I'm not sure why and I didn't spend much time trying to figure out why. I had better luck dumping to an intermediate wave file and then encoding that with QAAC called via foobar. Despite two steps the latter was definitely faster.
fijam
11th February 2016, 13:40
Are there plans to update eac3to to use ffmpeg's ac3 encoder instead of the long-abandoned libaften?
tebasuna51
11th February 2016, 18:38
Are there plans to update eac3to to use ffmpeg's ac3 encoder instead of the long-abandoned libaften?
Only madshi can answer that question.
BTW you can use for instance:
eac3to INPUT stdout.w64 | ffmpeg -i - -c:a ac3 -b:a 640k -center_mixlev 0.707 - OUTPUT.ac3
73ChargerFan
13th February 2016, 09:47
eac3to INPUT stdout.w64 | ffmpeg -i - -c:a ac3 -b:a 640k -center_mixlev 0.707 - OUTPUT.ac3
That should be memorialized in the first post.
tebasuna51
13th February 2016, 14:06
That should be memorialized in the first post.
Done. You can check if there are enough info.
Trizep
14th February 2016, 21:37
How can I deactivate libdcadec.dll in eac3to?
I prefer Arcsoft decoder.
:thanks:
Q-the-STORM
15th February 2016, 18:39
How can I deactivate libdcadec.dll in eac3to?
I prefer Arcsoft decoder.
:thanks:
you can force any decoder with -decodername... nero, arcsoft, sonic etc...
so just do e.g.
eac3to input.dtsma output.flac -arcsoft
Trizep
15th February 2016, 18:53
:thanks:
And in MeGUI ?
LigH
15th February 2016, 19:04
If MeGUI does not support custom parameters in its own dialogs, then feed your project with a prepared intermediate result. Converter GUIs are made to support the most probable cases. Support for unusual cases is nice but not mandatory.
heerschop
15th February 2016, 21:50
:thanks:
And in MeGUI ?
In Megui you can use the HD streams extractor to convert a DTS stream. MeGui uses eac3to to do the conversion. In the column "+options" you can add extra commands for eac3to. Double click in "+options column" for the given dts stream and add -arcsoft in the column. Now eac3to uses acrsoft decoder instead of the default decoder.
73ChargerFan
15th February 2016, 21:51
Done. You can check if there are enough info.
Impressive, thanks.
Trizep
16th February 2016, 16:01
:goodpost:
But I´ve to insert the +option each time?
There is no possibility to save the -arcsoft option?
(For the first I´ve copied eac3to 3.28 in MeGUI)
LigH
16th February 2016, 16:15
This is rather a question about how to use MeGUI, instead of how to use eac3to ... in contrast to encoder dialogs, the HD Stream Extractor has no preset management.
torturesauce
17th February 2016, 18:36
We have dcadec on foobar again! ^^
Rollinnn
22nd February 2016, 10:39
Hello!
It seems there is little problem with decoding DTS-HD MA. Resulted file has some offset in audio data.
How I tested this: source wav was encoded to DTS-HD MA using DTS-HD Master Audio Suite Encoder, then dtshd file decodec using eac3to (with libdcadec.dll from dcadec 0.2.0 github release), and resulted wav compared to original wav using binary comparator in foobar2000.
This problem not appears when dtshd is decoded with dcadec.exe.
Is this eac3to fault or libdcadec.dll fault?
Attached samples: source flac and dtshd created with DTS-HD Master Audio Suite Encoder.
Source (flac) (https://www.dropbox.com/s/he3mvbweik8oyss/source.flac?dl=0) , DTHS-HD MA (https://www.dropbox.com/s/nuq09kw39jsi0zd/DTSENC.dtshd?dl=0)
nevcairiel
22nd February 2016, 11:16
Thats probably the padding added by the DTS-HD Master Audio Suite. The audio is still bit-perfect, there is just a little more of it.
Rollinnn
22nd February 2016, 11:37
Thats probably the padding added by the DTS-HD Master Audio Suite.
But decoding with dcadec.exe gives file identical to source without any offset.
tebasuna51
22nd February 2016, 12:38
Thats probably the padding added by the DTS-HD Master Audio Suite. The audio is still bit-perfect, there is just a little more of it.
Yep. There are 2 extra silence frames at begining. After cut the first 21.333 ms the output is bit-perfect.
Flac file length: 8.757s
DTS decoded file length: 8.789s
Like the DTS have 824 frames the DTS output file length is correct.
But decoding with dcadec.exe gives file identical to source without any offset.
Please suply a link to the windows binary dcadec.exe used.
I decoded the dts with ffmpeg, LWlibavsource and eac3to-ArcSoft with identical output than eac3to-dcadec.
Rollinnn
22nd February 2016, 12:55
Please suply a link to the windows binary dcadec.exe used.
Official release from foo86 on github - https://github.com/foo86/dcadec/releases/download/v0.2.0/dcadec-0.2.0-win32.zip
nevcairiel
22nd February 2016, 13:25
The dtshd file format written by the DTS-HD Master Suite has some metadata that instructs the decoder to cut off a few frames at the beginning. dcadec probably respects that while others do not. This isn't really the case for any other DTS-HD stream, as a stream extracted from a Blu-ray, for example, would never have such metadata.
tebasuna51
22nd February 2016, 13:26
Using:
dcadec -S DTSENC.dtshd outS.wav
(-S Don't strip padding samples for streams within DTS-HD container.)
the output is bit-identical to eac3to output.
But using the default:
dcadec DTSENC.dtshd out_.wav
the output is bit-identical to source without delay.
Seems than dcadec.exe use the delay info in initial global header of DTSENC.dtshd (recently encoded by Master Audio Suite)
Is good to know that, but is useless with standard dtshd extracted from a container.
Rollinnn
22nd February 2016, 13:46
The dtshd file format written by the DTS-HD Master Suite has some metadata that instructs the decoder to cut off a few frames at the beginning. dcadec probably respects that while others do not.
Thanks. So this is eac3to or libdcadec.dll itself, who doesn't respect this data?
nevcairiel
22nd February 2016, 13:48
Thanks. So this is eac3to or libdcadec.dll itself, who doesn't respect this data?
eac3to in this case. But like tebasuna51 and myself said, its largely unimportant with real world data from actual discs.
marcusj0015
27th February 2016, 18:20
@madshi It would be AMAZING if you would add a trimming feature that didn't silently drop the MVC sub-stream (unlike FFmpeg).
I'd do it myself, but I'm currently working on a DTS Express decoder for DCADec.
Thunderbolt8
28th February 2016, 16:23
does anyone know if eac3to would recognize UHD BDs and their streams correctly? if not and if anyone has a readable disc with their drive, maybe these folks can cut samples.
sneaker_ger
28th February 2016, 17:17
UltraHD BluRay comes with a new copy protection that is yet to be cracked so there is no way to cut any samples or test with eac3to.
Also: I believe eac3to does not handle HEVC (codec used for 4k video on BluRay) video at all, irregardless of the container.
hubblec4
3rd March 2016, 18:33
Hi madshi
I use eac3to for a very long time, but this is the first time that eac3to don't recognize all mpls exactly.
eac3to v3.31
command line: "D:\eac3to.exe" "I:\"
------------------------------------------------------------------------------
1) 00027.mpls, 3:47:47
[0+1+2+3+4+64].m2ts
- Chapters, 35 chapters
- h264/AVC, 1080p24 /1.001 (16:9)
- DTS Master Audio, English, multi-channel, 48kHz
- AC3, English, stereo, 48kHz
- AC3, German, stereo, 48kHz
- AC3, Spanish, stereo, 48kHz
- AC3, French, stereo, 48kHz
- AC3, Italian, stereo, 48kHz
- AC3, Japanese, stereo, 48kHz
2) 00040.mpls, 00000.m2ts+00064.m2ts, 0:45:36
- Chapters, 7 chapters
- h264/AVC, 1080p24 /1.001 (16:9)
- DTS Master Audio, English, multi-channel, 48kHz
- AC3, English, stereo, 48kHz
- AC3, German, stereo, 48kHz
- AC3, Spanish, stereo, 48kHz
- AC3, French, stereo, 48kHz
- AC3, Italian, stereo, 48kHz
- AC3, Japanese, stereo, 48kHz
3) 00041.mpls, 00001.m2ts+00064.m2ts, 0:45:35
- Chapters, 7 chapters
- h264/AVC, 1080p24 /1.001 (16:9)
- DTS Master Audio, English, multi-channel, 48kHz
- AC3, English, stereo, 48kHz
- AC3, German, stereo, 48kHz
- AC3, Spanish, stereo, 48kHz
- AC3, French, stereo, 48kHz
- AC3, Italian, stereo, 48kHz
- AC3, Japanese, stereo, 48kHz
4) 00031.mpls, 00003.m2ts+00064.m2ts, 0:45:34
- Chapters, 7 chapters
- h264/AVC, 1080p24 /1.001 (16:9)
- DTS Master Audio, English, multi-channel, 48kHz
- AC3, English, stereo, 48kHz
- AC3, German, stereo, 48kHz
- AC3, Spanish, stereo, 48kHz
- AC3, French, stereo, 48kHz
- AC3, Italian, stereo, 48kHz
- AC3, Japanese, stereo, 48kHz
5) 00042.mpls, 00002.m2ts+00064.m2ts, 0:45:33
- Chapters, 7 chapters
- h264/AVC, 1080p24 /1.001 (16:9)
- DTS Master Audio, English, multi-channel, 48kHz
- AC3, English, stereo, 48kHz
- AC3, German, stereo, 48kHz
- AC3, Spanish, stereo, 48kHz
- AC3, French, stereo, 48kHz
- AC3, Italian, stereo, 48kHz
- AC3, Japanese, stereo, 48kHz
6) 00044.mpls, 00004.m2ts+00064.m2ts, 0:45:32
- Chapters, 7 chapters
- h264/AVC, 1080p24 /1.001 (16:9)
- DTS Master Audio, English, multi-channel, 48kHz
- AC3, English, stereo, 48kHz
- AC3, German, stereo, 48kHz
- AC3, Spanish, stereo, 48kHz
- AC3, French, stereo, 48kHz
- AC3, Italian, stereo, 48kHz
- AC3, Japanese, stereo, 48kHz
The mpls 00043 is not shown, but it is a normal episode like mpls 00044 or 00042.
Stereodude
3rd March 2016, 20:54
You can manually feed it 00043.mpls from the command line though, so is that really a problem?
73ChargerFan
3rd March 2016, 21:38
hubblec4,
To make matters worse, there is a copy protection scheme for movie blu-rays where the MPLS files are a bit scrambled, and there's hundreds of them, so it becomes difficult to find the correct MPLS for what you're looking for. When in doubt, I use MPC-BE to watch the playlist and confirm it is correct before taking the time to demux.
Caerbannog
3rd March 2016, 21:58
Apparently, the Avatar (James Cameron) 3D Blu-ray is still getting hit with the "the source file seems to be damaged" error when attempting to work on the first English subtitle stream. Is there a workaround or fix that can be applied to fix this? This is the first of all of my 3D BDs to have this issue. (I'm not a newbie, but I've never dealt with extracting individual streams if that's what it takes.) I'm currently using BDtoAVCHD v2.5.3.
M2TS, 2 video tracks, 4 audio tracks, 5 subtitle tracks, 2:41:42, 24p /1.001
1: Chapters, 35 chapters
2: h264/AVC (left eye), 1080p24 /1.001 (16:9)
3: h264/MVC (right eye), 1080p24 /1.001 (16:9)
4: DTS Master Audio, English, 5.1 channels, 24 bits, 48kHz, -9ms
(core: DTS, 5.1 channels, 1509kbps, 48kHz)
5: AC3, French, 5.1 channels, 384kbps, 48kHz, dialnorm: -27dB, -9ms
6: AC3, Spanish, 5.1 channels, 384kbps, 48kHz, dialnorm: -27dB, -9ms
7: AC3, Portuguese, 5.1 channels, 384kbps, 48kHz, dialnorm: -27dB, -9ms
8: Subtitle (PGS), English
9: Subtitle (PGS), French
10: Subtitle (PGS), Spanish
11: Subtitle (PGS), Portuguese
12: Subtitle (PGS), English
v03 Extracting video track number 3...
v02 Extracting video track number 2...
s08 Extracting subtitle track number 8...
v03 Creating file "C:\Users\Me\AppData\Local\Temp\BDtoAVCHD\AVATAR 3D-HSBS.job_0.mvc.h264"...
v02 Creating file "C:\Users\Me\AppData\Local\Temp\BDtoAVCHD\AVATAR 3D-HSBS.job_0.avc.h264"...
s08 Creating file "C:\Users\Me\AppData\Local\Temp\BDtoAVCHD\AVATAR 3D-HSBS.job_0.sup"...
s08 0:00:02 The source file seems to be damaged (discontinuity).
--
Interestingly, Disney's "Tangled" and "The Lion King" are supposed to be a victim of this, but I had no problem ripping those 3D BDs.
Sparktank
3rd March 2016, 22:59
Is there a workaround or fix that can be applied to fix this?
Try a different decrypter.
What did you use to decrypt? Try updating whatever it is.
MakeMKV updated recently to v1.9.9.
Clean the disc and/or drive lense?
Stereodude
3rd March 2016, 23:02
hubblec4,
To make matters worse, there is a copy protection scheme for movie blu-rays where the MPLS files are a bit scrambled, and there's hundreds of them, so it becomes difficult to find the correct MPLS for what you're looking for. When in doubt, I use MPC-BE to watch the playlist and confirm it is correct before taking the time to demux.
AnyDVD HD handles this. The .inf file it injects into the root folder of the disc tells you which playlist to use (if it had playlist obfuscation).
Caerbannog
4th March 2016, 00:01
Try a different decrypter.
What did you use to decrypt? Try updating whatever it is.
MakeMKV updated recently to v1.9.9.
Clean the disc and/or drive lense?
This doesn't appear to be an issue with the image but rather a case of how the subtitles are on the disc. Unfortunately, Avatar has forced subtitles, so without them some scenes won't make sense. This was originally reported in 2013 but appears to still be a problem. The bug that refers to this is http://bugs.madshi.net/view.php?id=87 but I was hoping that there was a workaround for the time being.
Q-the-STORM
4th March 2016, 00:19
Hi madshi
I use eac3to for a very long time, but this is the first time that eac3to don't recognize all mpls exactly.
[...]
The mpls 00043 is not shown, but it is a normal episode like mpls 00044 or 00042.
I am very sure 00043.mpls is a duplicate of 00031.mpls...
00027.mpls contains all 5 episodes 00000.m2ts, 00001.m2ts, 00002.m2ts, 00003.m2ts and 00004.m2ts....
eac3to is showing 5 additional playlists:
00040.mpls contains 00000.m2ts
00041.mpls contains 00001.m2ts
00042.mpls contains 00002.m2ts
00031.mpls contains 00003.m2ts
00044.mpls contains 00004.m2ts
all episodes are present...
it is not unusual for BDs to have duplicate playlists, it just happens to be that eac3to picked 31 instead of 43... but the m2ts files they contain should be exactly the same...
r0lZ
4th March 2016, 10:06
Apparently, the Avatar (James Cameron) 3D Blu-ray is still getting hit with the "the source file seems to be damaged" error when attempting to work on the first English subtitle stream. Is there a workaround or fix that can be applied to fix this? This is the first of all of my 3D BDs to have this issue. (I'm not a newbie, but I've never dealt with extracting individual streams if that's what it takes.) I'm currently using BDtoAVCHD v2.5.3.
It's a known bug of eac3to with some 3D-BDs.
In 3D BDs, the 3D movie is contained in 2 different M2TS files and one SSIF file at the same time. A M2TS contains the AVC video stream and all audio and subtitle streams. It's the M2TS that is referenced by the 2D playlist, and that is strictly compatible with the old 2D-only BD players. Another M2TS contains only the dependent (MVC) video stream, no audio and usually no subtitle stream. It is useless, since the MVC stream cannot be decoded without the AVC stream. The two M2TS are merged to form the SSIF file when the disc is mastered (or the ISO created). The SSIF contains therefore the two video streams, all audio streams, and all subtitle streams. It's the SSIF that is referenced by the 3D MPLS and decoded and played by a 3D BD player.
The problem is that sometimes (and notably in Avatar 3D), the second M2TS contains also the subtitle streams. (I have never understood why, but it's relatively frequent.) That subtitles have EXACTLY the same stream IDs that their equivalent in the first M2TS. Therefore, the final SSIF contains two times the same subtitle streams. And eac3to gets confused, because it tries to extract the two subtitle streams with the same ID from the SSIF as a single, unique stream. Of course, that causes timings conflicts, and it issues numerous error messages.
There is currently no solution, except to extract the subtitles from the first M2TS instead of the SSIF. You have to find the corresponding 2D MPLS to force eac3to to use the 2D M2TS. Unfortunately, not all 3D-BDs have a 2D MPLS. (I don't remember for Avatar.) And anyway, eac3to will probably hide it from its list of MPLS files, because it will consider the 2D MPLS as a duplicate of the 3D one, and remove it from the list.
The other solution is to use the relatively recent 3D version of tsMuxeR to demux the 3D MPLS. It handles the double subtitle streams well. (But take care anyway. It has other bugs. Personally, I use ONLY tsMuxeR v2.6.9. It seems that it's the only version that has no problems with the timings of some subtitle streams. It's that version that is distributed with BD3D2MK3D.)
hubblec4
4th March 2016, 10:07
@ Q-the-STORM
You are right, mpls 00031 seems to be the same like 00043.
Caerbannog
4th March 2016, 16:47
There is currently no solution, except to extract the subtitles from the first M2TS instead of the SSIF. You have to find the corresponding 2D MPLS to force eac3to to use the 2D M2TS. Unfortunately, not all 3D-BDs have a 2D MPLS. (I don't remember for Avatar.) And anyway, eac3to will probably hide it from its list of MPLS files, because it will consider the 2D MPLS as a duplicate of the 3D one, and remove it from the list.
The other solution is to use the relatively recent 3D version of tsMuxeR to demux the 3D MPLS. It handles the double subtitle streams well. (But take care anyway. It has other bugs. Personally, I use ONLY tsMuxeR v2.6.9. It seems that it's the only version that has no problems with the timings of some subtitle streams. It's that version that is distributed with BD3D2MK3D.)Ugh. I was hoping that after three years it would have been fixed, but I understand why it's not a priority if it only affects a handful of 3DBDs.
I doubt that there is anything 2D related with this. My disc is one of the Panasonic exclusives that they were distributing with their initial 3D Blu-ray players. Looks like I'll have to go out of my comfort zone to figure this out, but that's not necessarily a bad thing.
73ChargerFan
4th March 2016, 21:15
Another solution is to download a SRT version of the subtitle track.
r0lZ
5th March 2016, 11:26
SRT is not in 3D.
bmcelvan
11th March 2016, 14:44
Two quick questions.
Is there any point to using Arcsoft anymore when decoding DTS-HD MA of any kind, the libDcaDec seems to work for all, am I wrong?
Secondly, when using eac3tov3.31 when decoding DTS-HD MA 7.1, I get an error "libDcaDec reported the warning "XLL output not lossless"" and when using Arcsoft I get the message "volume will be low". If I simply use eac3tov3.30 without Arcsoft, I get no errors reported at all.
Any ideas?
Thanks Ben
tebasuna51
11th March 2016, 15:58
Is there any point to using Arcsoft anymore when decoding DTS-HD MA of any kind, the libDcaDec seems to work for all, am I wrong?
Arcsoft is necessary for DTS-Express only, BTW remain like a option for users than prefer it.
...when decoding DTS-HD MA 7.1, I get an error "libDcaDec reported the warning "XLL output not lossless""
Don't worry about that. Maybe are frames than not need lossless subframes (XLL), for instance silent frames.
...and when using Arcsoft I get the message "volume will be low"
Only when DTS-MA is "strange setup" ArcSoft remix the output channels forcing to have less volume than original. libDcaDec don't remix the channels.
Atak_Snajpera
16th March 2016, 15:09
I must say that built-in flac encoder could be faster. This method is about 2.5x faster than regular command.
eac3to.exe drive_video_10min.mkv 2:stdout.wav | CUETools.FLACCL.cmd.exe --ignore-chunk-sizes --opencl-type CPU --opencl-platform "Intel(R) OpenCL" -o c:\temp\audio.flac -
10min 5.1 DTSMA -> 5.1 FLAC
CPU: Xeon E5-2690 @ 2.9 GHz (8C/16T)
eac3to Built-in encoder : 64s (Encoder+Decoder CPU usage: 7%)
FlacCL (Intel Platform) : 26s (Decoder CPU usage: 7% , Encoder CPU usage: 5%)
FlacCL (AMD platform) : 115s (Decoder CPU usage: 2% , Encoder CPU usage: 67%)
Regarding Intel Platform. It clearly shows that decoder is a bottleneck here because 7% means full single core utilization.
I'm really disappointed with AMD platform. Despite nice multi-threading encoding is very slow.
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.