eac3to - audio conversion tool

[SeeMoreDigital]

I don't know much about DSD, but according to Wikipedia it's comparable to 20 bit, 96kHz PCM, so a 24 bit flac file should be quite adequate.If you're interested, Oppo Digital prefer to transcode DSD 64 (single-rate) to PCM @ 88.2KHz/24-bit.

Mathematically the file size of a DSD 64 stream works out at almost the same file size as an PCM stream @ 88.2KHz/32-bit ;)


Cheers

[Groucho2004]

I wonder if there is any hardware recording audio with up to 32 bit precision.Even high end audio interfaces max out at -130 dB THD+N, still below 24 bit resolution.

signal-to-noise ratio even below the 24 bit treshold (don't remember exactly where it was, 120 dB?).
20 x log(1/(2^24)) = -144 dB. :D

So in most practical cases, 32 bit precision would be an illusion, lying on a big fluffy carpet of noise.
Yep.

[foxyshadis]

thats right in theory,
but eac3to/libav ac3 encoder has wrong bandwidth in lower Bitrates for 5.1 like 384 (14 kHz) / 448 (16 kHz) vs Studio AC3 384 (18 kHz) / 448 (20 kHz)

Remember that for every bit you spend on a high frequency you have to spend one less bit on a lower frequency. If you can't hear that frequency, if your speakers can't properly represent it, or if including more high frequencies results in audible distortion across the spectrum, then you're better off severely low-passing. At those bitrates for 5.1, I would lowpass even if eac3to didn't do it for me. (Instead I used newer codecs that can easily handle low rates.)

[foxyshadis]

I want to concert a DSD (.DFF) audio file losslessly to Flac, because Winamp cant play DSD and the wasapi Plugin cannot play flac files with 176 kHz (only 96 and 192; also no 32-bit flac files; and no, i dont want to change my audio player)

DSD128 is 5.6 MHz, if you have 176kHz then it's already been converted to PCM. Winamp's plugin will never be updated, so you should use software that directly decodes it to 96 or 192kHz instead (even 96 is probably overkill) to eliminate any possibility of loss... but even SSRC conversion will have only the absolute minimum difference, far below anything measurable.

[ZMachine95]

hello guys and girls, I would like to convert some BDMV's folders. I would like to use eac3to to to get the correct mpls file and send all tracks on ffmpeg stdin and convert.

I have thought about using something like that..

but it doesn't work. If I use only stdout.h264 the video track is piped to ffmpeg and converted.

eac3to J:\BDMV\ 1) stdout.mkv | ffmpeg.exe -hwaccel auto -y -i - -map 0:v:0 -c:v libx265 -crf 20.0 -preset veryfast -map 0:a:0 -c:a:0 libvorbis -b:a:0 192k -map 0:a:1 -c:a:1 libvorbis -b:a:1 192k -map 0:s:0 -c:s:0 copy -map 0:s:1 -c:s:1 copy -map 0:s:2 -c:s:2 copy "H:\output.mkv"

What am I doing wrong? or there is a fast way to do that?... I don't actually have to use only ffmpeg and eac3to..

thanks guys

Someone can help me?

[Music Fan]

if including more high frequencies results in audible distortion across the spectrum
When and why does it happen ?

[LigH]

@ ZMachine95:

Not sure why. But maybe MKV is not really a streamable format. It is a container to keep video and audio (etc.) in sync; so it may need to get values in its header up-to-date which are only known after writing the MKV out has finished. Check if it works in two steps (eac3to writing the MKV to disc, then ffmpeg processing it afterwards).

Or wait for people more experienced with eac3to ripping Blu-rays to MKV.

[tebasuna51]

Someone can help me?
Nope.

eac3to uses Haali to create mkv's with only video, not full mkv's with all tracks, then is useless for you even if work your sintax.

I'm surprised than work with stdout.h264.

[DarkSpace]

hello guys and girls, I would like to convert some BDMV's folders. I would like to use eac3to to to get the correct mpls file and send all tracks on ffmpeg stdin and convert.

I have thought about using something like that..


eac3to J:\BDMV\ 1) stdout.mkv | ffmpeg.exe -hwaccel auto -y -i - -map 0:v:0 -c:v libx265 -crf 20.0 -preset veryfast -map 0:a:0 -c:a:0 libvorbis -b:a:0 192k -map 0:a:1 -c:a:1 libvorbis -b:a:1 192k -map 0:s:0 -c:s:0 copy -map 0:s:1 -c:s:1 copy -map 0:s:2 -c:s:2 copy "H:\output.mkv"


but it doesn't work. If I use only stdout.h264 the video track is piped to ffmpeg and converted.

What am I doing wrong? or there is a fast way to do that?... I don't actually have to use only ffmpeg and eac3to..

thanks guys

Just so you know, all that eac3to does when it outputs mkv is to mux the video track. No audio, no subtitles, no chapters, just a container and its video track.
I think that should explain your particular problem.

Now, what you could try is to make eac3to join the individual m2ts files into a single m2ts and pipe that to ffmpeg. I have no idea if this works (depends on whether m2ts is streamable), but I rather expect it to. Use something like this:

eac3to 00001.mpls stdout.m2ts | ffmpeg -i - -o output.mkv


Things you'll need to test:

Does stdout.m2ts work as expected?
Can eac3to output joined m2ts files from a playlist file, or do you need to manually input the individual m2ts files?
Is the m2ts format streamable, or does ffmpeg need to seek in the file to properly decode/split it? I guess that it is streamable, but I don't know.

[LigH]

This may just be a case where eac3to is not the optimal tool.

[Smithy]

Remember that for every bit you spend on a high frequency you have to spend one less bit on a lower Frequency. If you can't hear that frequency, if your speakers can't properly represent it, or if including more high frequencies results in audible distortion across the spectrum, then you're better off severely low-passing. At those bitrates for 5.1, I would lowpass even if eac3to didn't do it for me. (Instead I used newer codecs that can easily handle low rates.)

Yes of Course, but cut-off Frequencies below lossy core Sources is nogo!
Save max possible Quality for Audio Reencodes is best way and its not a Big Deal to use Higher or Max Bitrates for more bits @ lower Frequencies.
Everyone takes different perception to hear frequencies itself and by Setups.
This is not a question what you can hear or other can or not, because @ eac3to/libav that most people used, have no Control of bandwidth option or lowpass.
AftenGui or wavtoac3enc (don't know ffmpeg) have more Control about bandwidth per Bitrate, bandwidth lowpassfilter, LFE lowpassfilter or Dialnorm.
Before make encode of AC3, a Normalize of -3dB or more is needed, against Clipping that depend on the source.
And lower bitrate/bandwidth Encodes guaranteed more clipping and DC-offset ... check the decoded wavs from reencoded AC3.

[Boulder]

As we've seen some discussion regarding the 3/1-channel files, can anyone help me to convert such an audio track to a standard 5.1ch track to avoid any playback issues? I think I've seen such an operation somewhere here, but couldn't find it anymore.

Opusenc just gives me this:

WARNING: Unknown WAV surround channel mask: 263
Blindly mapping speakers using default SMPTE/ITU ordering.
Encoding using libopus 1.1.1-beta-24-g66611f1-dirty (audio)
-----------------------------------------------------
Input: 48kHz 4 channels
Output: 4 channels (4 coupled)
20ms packets, 240kbit/sec VBR
Preskip: 312

It seems that it's guessing 2 front and 2 surround channels.

[Music Fan]

As we've seen some discussion regarding the 3/1-channel files, can anyone help me to convert such an audio track to a standard 5.1ch track to avoid any playback issues?
You can maybe create 2 empty waves for the rear channels to accompany your 4 channels.

[tebasuna51]

...
It seems that it's guessing 2 front and 2 surround channels.

Nope, channel mask 263 is FL,FR,FC,BC (3 front and 1 surround).
You can use sox (eac3to can't do that):

sox 4w310.wav 6w51.wav remix -m 1 2 3 3v0 4v0.7071 4v0.7071

Silent LFE and BC to SL,SR (half volume each).

[Boulder]

Thanks, I'll use that from now on in those rare cases :)

[adhaing]

for instance:

eac3to input stdout.w64 | ffmpeg -i - -c:a ac3 -b:a 640k output.ac3

Weird that for direct streaming like this, when
eac3to 6ch-24bit.dtshd stdout.w64 | ffmpeg -i - -c:a ac3 -b:a xxxk
the process would always stop at around time=01:22:46 where the virtual .w64 just exceeded 4GB (of course no actual .w64 generated in this case). Then eac3to wailed with the log
The W64 writer couldn't seek to the header. <ERROR>
Aborted at file position 5103389848. <ERROR>
Decoded either with ArcSoft or DCA, the same results.


However, when I created an intermediate .w64 at first with eac3to (up to 7GB), then fed it into ffmpeg, everything was fine.


I know now ffmpeg itself could properly handle dtshd-ma5.1, but I'm just wondering what's wrong with the direct piping/streaming of the loyally unlimited .w64?


Cheers.

[tebasuna51]

the process would always stop at around time=01:22:46 where the virtual .w64 just exceeded 4GB (of course no actual .w64 generated in this case). Then eac3to wailed with the log
The W64 writer couldn't seek to the header. <ERROR>
Aborted at file position 5103389848. <ERROR>
...
I know now ffmpeg itself could properly handle dtshd-ma5.1, but I'm just wondering what's wrong with the direct piping/streaming of the loyally unlimited .w64?

There are two problems like you can see in my last post (http://forum.doom9.org/showthread.php?p=1726046#post1726046) about that:

1) When eac3to begin to write the pipe output (stdout.w64) don't know the whole length of the data and put a temporal header with a size of 4GB (like put with a stdout.wav) and ffmpeg stop to encode at this size (the size of a wav 5.1 24 bits 48 KHz 01:22:46).

This problem can be solved putting a temporal bigger size (for instance 1TB). The fields for sizes in w64 have 64 bits, just for solve the 4GB wav limit because the equivalents fields have only 32 bits and don't support values greater 4GB.

2) When eac3to finish to decode know the correct data length, and try to rewrite the w64 header with the correct value, if the output is a w64 file the process finish ok, but can't rewrite the piped output and abort with the
The W64 writer couldn't seek to the header. <ERROR>
Aborted at file position 5103389848. <ERROR>

Even if the size is less than 4GB this eac3to abort can cause a ffmpeg error because the last audio data can be incomplete
[pcm_s24le @ 0000000002d19700] Invalid PCM packet, data has size 8 but at least a size of 18 was expected
Error while decoding stream #0:0: Invalid data found when processing input

The problem can be solved if eac3to don't try to rewite the piped w64 header and don't abort (like don't abort with piped wav).
ffmpeg can stop without errors when finish the piped data, even if the size expected is greater (1 TB) than the received data.

[ron spencer]

any reason why an Atmos file crashes eac3to...using 3.29

error I get is:

The libav decoder reported error -1094995529 while decoding. I just want to convert to AC3 448

thx

[Elegant]

If only you could offset by samples...

[ZMachine95]

Just so you know, all that eac3to does when it outputs mkv is to mux the video track. No audio, no subtitles, no chapters, just a container and its video track.
I think that should explain your particular problem.

Now, what you could try is to make eac3to join the individual m2ts files into a single m2ts and pipe that to ffmpeg. I have no idea if this works (depends on whether m2ts is streamable), but I rather expect it to. Use something like this:

eac3to 00001.mpls stdout.m2ts | ffmpeg -i - -o output.mkv


Things you'll need to test:

Does stdout.m2ts work as expected?
Can eac3to output joined m2ts files from a playlist file, or do you need to manually input the individual m2ts files?
Is the m2ts format streamable, or does ffmpeg need to seek in the file to properly decode/split it? I guess that it is streamable, but I don't know.


thanks man.. i'll give it a try :)

EDIT: does not work... I have tried to use mkvmerge but has no support for pipelining.. I guess the only way is to use mkvmerge and mux locally then use the mkv file as input for ffmpeg

[LigH]

There are containers which need to work on physical files, to have a chance to write correct header values after the whole file has been processed. Pipes are unable to rewind.

[Devrim]

When eac3to shows only 1 playlist, is that 100% the correct playlist? (Lets assume the bluray has been ripped properly)

I know some companies throw some fake playlists (changing scenes, stopping halfway) on blurays, does eac3to detect those properly?

[Snowknight26]

No. It only sorts the playlists by length.

[Devrim]

No. It only sorts the playlists by length.

But does it detect all playlists correctly? (So in the end, 1 playlist = the correct playlist anyways)

[Snowknight26]

It'll read the MPLS files and display them (well, any above 30 minutes from what I recall), but it's your job to figure out which one is the correct one, especially if there are hundreds of others of similar durations.

[LigH]

If there is only one playlist on the disk, where should another fake playlist come from? AFAIK, it is not like DVD Video where the contents of the ISO-9660 and the microUDF file systems may differ, Blu-ray video has only one UDF 2.50 file system, no ISO-9660 compatibility layer for PCs (current PC operating systems can access UDF-only disks with appropriate drivers). There must be at least one valid playlist so that a real consumer Blu-ray player can play the movie correctly. If there is no other, there is no other fake one.

[r0lZ]

In my experience, there are often several playlists with (exactly or almost) the same content. They are not "fake" playlists. Just dupes. For example, it is not unusual to find a playlist with several languages except Chinese, and another playlist with the same content, but only the Chinese audio and subtitles. Also, on 3DBDs, the same playlist may be present in 2D (without the 3D extensions) and in 3D (with the reference to the MVC stream). But the 3D playlist can be duplicated too, with one playlist containing the references to the 3D-Planes (used to decode the subtitles in 3D), and the other playlist without the 3D-Planes (and therefore "less good", although the MPLS files referenced are exactly identical). And playlists exactly identical are usual too, for a reason I have never understood. In multi-angle BDs, there are often also simple playlists that reference only a single M2TS. That doesn't make sense, since if you play them you see only a short part of the movie. I suppose they are remnants of the abstract layer of the authoring program.

Anyway, there is no rule, and you can't say for sure what is the "best" playlist to use without examining carefully their content and variants.

And I can confirm that when several playlists have the same content (in term of referenced MPLS files) eac3to shows only one of them, but unfortunately not always the "best" playlist. To be sure, you have to display the information of all playlists, one at a time. Or write your own MPLS parser.

[tebasuna51]

Seems madshi found many samples about the related problem, changelog items:

v3.19
* added support for 3D Blu-Rays (playlists, detection & demuxing)
v3.00
* workaround for movie playlists which want the same m2ts file played twice
v2.85
* fixed: v2.84 sometimes chose wrong m2ts playlist file
v2.66
* when there are 2 similar playlists the one with less chapters is ignored now
v2.59
* added workaround for Blu-Ray playlists with multiple last "invalid" parts
v2.58
* added workaround for Blu-Ray playlists with a last small "invalid" m2ts part
v2.45
* Blu-Ray angles are now reported as separate titles
* duplicate playlists are not listed in the "folder view", anymore

But, of course, maybe there are exceptions not solved.

EDIT:
I read complex workarouds to know the "correct" playlist than a BDplayer uses by default (search the mpls file in use by the OS) but nothing about how found that info in BD data.

[Xorp]

When I convert TrueHD 7.1 Atmos to FLAC, what happens to the Atmos information? Is it dropped or mixed in?

[sneaker_ger]

It's not used. There is no free Atmos decoder.

[Xorp]

What I suspected, thanks

[rapscallion]

When I convert TrueHD 7.1 Atmos to FLAC, what happens to the Atmos information? Is it dropped or mixed in?
Will conversion/decoding to wavs be done correctly (without Atmos info of course)

I tried it and it completed without errors, however, there's no way I can verify that it's correct.

[Stereodude]

I tried it and it completed without errors, however, there's no way I can verify that it's correct.
By that standard don't you have the same issue with any conversion it makes? How do you know that non-Atmos conversions are correct?

[rapscallion]

Because I have unwavering faith in Madshi. However, the latest release of eac3to was prior to the introduction of Atmos.

[Boulder]

Because I have unwavering faith in Madshi. However, the latest release of eac3to was prior to the introduction of Atmos.One reason for the release of the latest version was to handle Atmos correctly (to ignore it) :)

[rapscallion]

I guess it would have helped if I had read the change log : )

[radigast]

I have 2 questions regarding TrueHD demuxing bugs I am experiencing:

1. Is the .thd+ac3 / .ac3 switch currently broken on TrueHD tracks for eac3to?
2. Is the .thd switch currently working incorrectly by giving the TrueHD file and embedded AC3 "core"?

Specifics:

1. TrueHD demuxing with eac3to 3.29 is throwing some errors and is unable to output any file. I am attempting to demux a TrueHD stream from a BD using the following commands (a log file isn't generated, as the command window simply freezes until I ctrl-c it):
eac3to.exe 00001.mpls 1) 3: 00001.mpls.thd+ac3
eac3to.exe 00001.mpls 1) 3: 00001.mpls.ac3
Both of these commands cause the error:The libav decoder reported error -1094995529 while decoding....which freezes the command window, and yields no output.

2. Using the .thd extension successfully yields a working .thd file (strangely enough, with the embedded 640 kbps AC3 "core"). My understanding is that using the .thd extension is supposed to only give the actual "coreless" .thd file. The command used here is:
eac3to.exe 00001.mpls 1) 3: 00001.mpls.thd

The BD in question has the following structure:M2TS, 1 video track, 1 audio track, 2 subtitle tracks, 1:28:08, 24p /1.001
1: Chapters, 12 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: TrueHD, English, 5.1 channels, 48kHz
4: Subtitle (PGS), English
5: Subtitle (PGS), Spanish

Any thoughts / confirmation / input on this?

[sneaker_ger]

There have been reports that mighty be related:
http://forum.doom9.org/showpost.php?p=1730781&postcount=13349
http://forum.doom9.org/showpost.php?p=1733150&postcount=13420

I suggest your open a report on madshi's bug tracker about the problem and include a sample file. Without a sample it might be difficult to fix for madshi.
http://bugs.madshi.net/

[radigast]

There have been reports that mighty be related:
http://forum.doom9.org/showpost.php?p=1730781&postcount=13349
http://forum.doom9.org/showpost.php?p=1733150&postcount=13420

I suggest your open a report on madshi's bug tracker about the problem and include a sample file. Without a sample it might be difficult to fix for madshi.
http://bugs.madshi.net/Thanks for the heads-up. I would love to submit a sample. However, eac3to is what I usually use to create samples...which is problematic because it doesn't work for these specific videos. Any ideas what else I can use to make samples?

[sneaker_ger]

Try cutting out the first ~50 MB of the respective m2ts using e.g. DGSplit (http://rationalqm.us/dgsplit/dgsplit12.zip). If you can reproduce the problems with this small sample you are good to go. (Not sure if it makes also sense to include the playlist files)

[Music Fan]

You can also use TSMuxer to cut or join ts, m2ts, mp4, mov ... (never heard of DGSplit).

[tebasuna51]

1) Your 00001.mpls have only one .m2ts?

Use
eac3to "BD_FOLDER\"
to obtain a log than show how many .m2ts have your 00001.mpls.

If there are more than one, load each one with eac3to and verify than the track 2 (m2ts don't have Chapters and now first audio is track 2) have always the same format, for instance:

2: TrueHD/AC3, English, 5.1 channels, 48kHz
(embedded: AC3, 5.1 channels, 640kbps, 48kHz)

eac3to can't join the track if one of them have a different format.

2) Your BD is a correct rip from a original BD or is a downloaded one?
In first case say us the method used to rip the BD to hard disk.
In second case we can't help you and maybe is a corrupt one.

[radigast]

The playlist only links to a single .m2ts file; there is no seamless branching.

I split that .m2ts file into 50mb pieces and tested several pieces. I was able to successfully extract the TrueHD stream as both .ac3 and .thd+ac3 for each piece with no errors. However, when I tried on the unsplit .m2ts file (and when also loading via the playlist), I received the same error I had posted before.

Any other ideas / suggestions?

[Snowknight26]

If you want to get your hands dirty, you could run Process Monitor to see how far eac3to.exe reads into the file, then you'll have a rough approximation as to where in the file the error occurs.

[radigast]

If you want to get your hands dirty, you could run Process Monitor to see how far eac3to.exe reads into the file, then you'll have a rough approximation as to where in the file the error occurs.Oh, I want dirty hands. I have only ever used Process Monitor once, though. Help me get these hands dirty, please!

(What sort of filters should I put in place?)

[Snowknight26]

Something like 'Process is eac3to.exe' and 'Path contains .m2ts' should suffice.

[radigast]

Finally found some time this week...

I used ProcMon with the exact filters you suggested.

The BD in question has the following streams:
M2TS, 1 video track, 1 audio track, 2 subtitle tracks, 1:28:08, 24p /1.001
1: Chapters, 12 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: TrueHD, English, 5.1 channels, 48kHz
4: Subtitle (PGS), English
5: Subtitle (PGS), Spanish

First, I tried to demux the TrueHD stream as .thd+ac3.
eac3to.exe "J:\BDMV\PLAYLIST\00001.mpls" 1) 3: 00001.mpls.thd+ac3
This immediately produced the same error I mentioned before:The libav decoder reported error -1094995529 while decoding.
The ProcMon log is here: http://pastebin.com/M77XQh7f

Second, I tried to demux the TrueHD stream as .ac3.
eac3to.exe "J:\BDMV\PLAYLIST\00001.mpls" 1) 3: 00001.mpls.ac3
This yielded the same error as above.
The ProcMon log is here: http://pastebin.com/Lc5a2SuH

Again, if I manually cut the sole .m2ts file this playlist refers to into pieces, both commands work fine.

Any ideas?

[Snowknight26]

Unfortunately your logs don't show any ReadFile operations so we still don't know where exactly in the file the error occurs.

If it matters, that error means "Invalid data found when processing input" though.

[Smithy]

Any Chance to Decode DD+ / EAC3 @ 7.1 in the next time ?

[Smithy]

eac3to 3.29

DTS, 5.1 channels, 2:16:09, 755kbps, 48kHz

Arcsoft 1.1.0.0 (Abort @ 99%)

dts, 48000, 5.1
Decoding with ArcSoft DTS Decoder...
Patching bitdepth to 24 bits...
Writing WAVs...
The ArcSoft DTS Decoder reported an error while decoding. <ERROR>
Aborted at file position 760479744. <ERROR>


DcaDec (Abort @ 99%)

dts, 48000, 5.1
Decoding with libDcaDec DTS Decoder...
Patching bitdepth to 24 bits...
Writing WAVs...
The libDcaDec DTS Decoder reported the error "Invalid bitstream format" while decoding. <ERROR>
Aborted at file position 760479744. <ERROR>


Libav/FFMpeg (Abort @ 99%)

dts, 48000, 5.1
Patching bitdepth to 24 bits...
Decoding with libav/ffmpeg...
Writing WAVs...
[libav] LFEScaleIndex larger than 127 <WARNING>
[libav] If you want to help, upload a sample of this file to ftp://upload.ffmpeg.org/MPlayer/incoming/ and contact the ffmpeg-devel mailing list. <WARNING>
[libav] error decoding block <WARNING>
The libav decoder reported error -1094995529 while decoding. <ERROR>
Aborted at file position 760479744. <ERROR>


Sonic 4.3.0.169 (100% OK)

dts, 48000, 5.1
Patching bitdepth to 24 bits...
Decoding with DirectShow (Sonic Audio Decoder)...
DirectShow reports 5.1 channels, 24 bits, 48kHz
Writing WAVS...
Done.


DTS Aborted Sample (10s)
http://workupload.com/file/mp9Z1lJw