eac3to - audio conversion tool

[GCRaistlin]

Yes, sorry, I've mixed up frames and samples. But I still don't understand: doesn't "-edit=0:00:00,+96 ms -silence" mean "add 96 ms of silence to the beginning of the file"? In other words, isn't it equal to "+96 ms"?

[GCRaistlin]

How to take the last minutes of the ac3 file to the wav file with the one command? This:

eac3to file.ac3 file.wav -7200000ms

doesn't work as expected (file.wav is 2:34:01 long, while file.ac3 is 2:04:53 long).

[Snowknight26]

Use a program that can edit WAV files.

[GCRaistlin]

Snowknight26, your answer doesn't concern my question. I wonder why this:

eac3to file.ac3 file2.ac3 -7200000ms
eac3to file2.ac3 file2.wav

gives me what I want while the cmdline above doesn't.

[Snowknight26]

It does fix your problem though.

Sure, it does seem like a bug but I don't think the intention of being able to change a track's delay extended to cutting off 2 hours of audio.

[tebasuna51]

@madshi
I added a feature request Use ffmpeg like external encoder (http://bugs.madshi.net/view.php?id=310)
Copied here:

To use ffmpeg like external encoder I make some test:

1) eac3to input stdout.wav | ffmpeg -i - -c:a ac3 -b:a 640k wav.ac3

- eac3to send to stdout a wav header with RIFF_length and data_length near to 4 GB, and finish without errors.

- ffmpeg seems work fine with short audios, thats means than do a implicit -ignorelength with piped data.

- Of course with data > 4 GB ffmpeg cut the encode and finish with a file short than input.


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

- eac3to send to stdout a w64 header with riff_length and data_length near to 4 GB, and finish with this ERROR, with any input length:

Writing W64...
Creating file "stdout.w64"...
The W64 writer couldn't seek to the header. <ERROR>
Aborted at file position 1886250. <ERROR>

- ffmpeg work until the eac3to crash, but output a encode short than input and a error like:

[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

3) I test ffmpeg piping a w64 file with riff_length and data_length greater than file length and work fine.

Then we can use stdout.w64 with two simple changes, I think, in eac3to:

a) Don't abort with:
The W64 writer couldn't seek to the header. <ERROR>
Like don't abort when use stdout.wav

b) Put a higer value in fields riff_length and data_length of w64 header. Maybe 1 Tera is enough.

[FireFreak111]

I am trying to extract a TrueHD track from a damaged .ac3 file thats recognised as a H264 file in MKVMerge. When I extract it, compared to the other .ac3 files I am extracting TrueHD tracks from, 'This Track begins with a non-major frame' pops up. This I believe is responsible for the first ~15 seconds of the file either not being decoded or something, causing massive sync issues when muxing the file (audio starts 10-15 seconds or so early). It's the only one where that message pops up, and the only one out of 25 files that has this sync problem. Any idea on how to fix this?

[r0lZ]

Not sure how to recover the missing 16 seconds, but you can add a delay with MkvMerge (in the tab "Format Specific Options") to re-sync the audio properly.

[FireFreak111]

Not sure how to recover the missing 16 seconds, but you can add a delay with MkvMerge (in the tab "Format Specific Options") to re-sync the audio properly.

That does fix the sync, but yeah, no audio plays for a while, which for this audio file is a problem.

[Soulvomit]

How do I get 8.5 minutes of a 145-minute track 25 minutes in? Is sample-accurate editing possible?

[gp2221]

I used to use 'Another EAC3to GUI' to create MKVs from my Blu-rays. However, I had problems with my hard disk and ended up replacing it and reinstalling my OS (Windows 7 Ultimate x64) and all my programs. Unfortunately, I couldn't get 'Another EAC3to GUI' to work because of a problem with the ArcSoft DTS decoder. I had a legal copy of ArcSoft TMT3, but couldn't get past the 30-day trial. The registration no longer works because TMT3 is a discontinued product. Even though I had the dtsdecoder.dll from the trial installed, I couldn't get 'Another EAC3to GUI' to recognize it. ArcSoft even gave me a new legal copy of TMT6 and I can't get it to work with the decoder from that, either.

I liked that 'Another EAC3to GUI' could generate the audio, video, chapter and subtitle files separately, which I could merge together with MKVmerge (I think the latest version is MKVToolNix GUI). This lets me generate audio-only files from concert Blu-rays. I could use the chapter file to create a CUE file, which I used to to generate FLACs for every track.

So, now that the latest version of eac3to can decode DTS-HD MA, is there an alternative to 'Another EAC3to GUI' that will extract the audio/video + chapters and subtitles?

[Nebudchanezzer]

I used to use 'Another EAC3to GUI' to create MKVs from my Blu-rays. However, I had problems with my hard disk and ended up replacing it and reinstalling my OS (Windows 7 Ultimate x64) and all my programs. Unfortunately, I couldn't get 'Another EAC3to GUI' to work because of a problem with the ArcSoft DTS decoder. I had a legal copy of ArcSoft TMT3, but couldn't get past the 30-day trial. The registration no longer works because TMT3 is a discontinued product. Even though I had the dtsdecoder.dll from the trial installed, I couldn't get 'Another EAC3to GUI' to recognize it. ArcSoft even gave me a new legal copy of TMT6 and I can't get it to work with the decoder from that, either.

I liked that 'Another EAC3to GUI' could generate the audio, video, chapter and subtitle files separately, which I could merge together with MKVmerge (I think the latest version is MKVToolNix GUI). This lets me generate audio-only files from concert Blu-rays. I could use the chapter file to create a CUE file, which I used to to generate FLACs for every track.

So, now that the latest version of eac3to can decode DTS-HD MA, is there an alternative to 'Another EAC3to GUI' that will extract the audio/video + chapters and subtitles?

You can still use "Another EAC3to GUI" just add "-dcadec" after the FLAC filename in the commandline option.

[gp2221]

You can still use "Another EAC3to GUI" just add "-dcadec" after the FLAC filename in the commandline option.
Will I need to edit the command line every time I run it, of is there a way to make this change the default?

[Plazik]

I've got BD with TV show where each series at the beginning have left saver:
http://i70.fastpic.ru/thumb/2015/0613/ac/67ec1cf324287bdc09d8af853ceca8ac.jpeg (http://fastpic.ru/view/70/2015/0613/67ec1cf324287bdc09d8af853ceca8ac.png.html)
It doesn't shows when I'm plaing playlist but it shows if I'm plaing m2ts file.

BD log:
eac3to v3.29
command line: "C:\Program Files (x86)\MeGUI\tools\eac3to\eac3to.exe" "J:\" -log="filename.txt"
------------------------------------------------------------------------------
1) 00046.mpls, 00037.m2ts, 0:47:14
- Chapters, 6 chapters
- h264/AVC, 1080p24 /1.001 (16:9)
- DTS Master Audio, English, multi-channel, 48kHz
- DTS Master Audio, French, multi-channel, 48kHz

2) 00049.mpls, 00041.m2ts, 0:43:05
- Chapters, 6 chapters
- h264/AVC, 1080p24 /1.001 (16:9)
- DTS Master Audio, English, multi-channel, 48kHz
- DTS Master Audio, French, multi-channel, 48kHz

3) 00048.mpls, 00040.m2ts, 0:43:04
- Chapters, 6 chapters
- h264/AVC, 1080p24 /1.001 (16:9)
- DTS Master Audio, English, multi-channel, 48kHz
- DTS Master Audio, French, multi-channel, 48kHz

4) 00050.mpls, 00053.m2ts, 0:43:01
- Chapters, 6 chapters
- h264/AVC, 1080p24 /1.001 (16:9)
- DTS Master Audio, English, multi-channel, 48kHz
- DTS Master Audio, French, multi-channel, 48kHz

5) 00045.mpls, 00054.m2ts, 0:16:34
- Chapters, 4 chapters
- h264/AVC, 1080p24 /1.001 (16:9)
- AC3, English, stereo, 48kHz
- AC3, English, stereo, 48kHz


Playlist has a right duration 00046.mpls, 00037.m2ts, 0:47:14.

But detailed information of the playlist has another information 0:50:03:

eac3to v3.29
command line: "C:\Program Files (x86)\MeGUI\tools\eac3to\eac3to.exe" "J:\" 1) -log="filename.txt"
------------------------------------------------------------------------------
M2TS, 1 video track, 2 audio tracks, 8 subtitle tracks, 0:50:03, 24p /1.001
1: Chapters, 6 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: DTS Master Audio, English, 5.1 channels, 24 bits, 48kHz
(core: DTS, 5.1 channels, 768kbps, 48kHz)
4: DTS Master Audio, French, 5.1 channels, 24 bits, 48kHz
(core: DTS, 5.1 channels, 768kbps, 48kHz)
5: Subtitle (PGS), English
6: Subtitle (PGS), French
7: Subtitle (PGS), Danish
8: Subtitle (PGS), Dutch
9: Subtitle (PGS), Finnish
10: Subtitle (PGS), Norwegian
11: Subtitle (PGS), Swedish
12: Subtitle (PGS), French


I can't demux video and audio correct.

[Bigmango]

Hi,

Is there a problem with the FLAC 4 channel mapping?

This is my DTS-HDMA track:
Channel(s) : 4 channels
Channel positions : Front: L C R, Back: C

But according to the FLAC specs, this is the assignment for 4 channels:
3 channels: left, right, center
4 channels: front left, front right, back left, back right

Makemkv outputs an error, explaining that the channel mapping will be wrong as FLAC doesn't support these 4 channels correctly.

eac3to detects this as 3.1. But will the channel layout be right?

Thanks.

[nevcairiel]

eac3to will write metadata to the FLAC file which sets the appropriate channel layout beyond what the FLAC spec allows - it then entirely depends on your playback application if it can read this metadata and properly make use of it.

[Bigmango]

eac3to will write metadata to the FLAC file which sets the appropriate channel layout beyond what the FLAC spec allows - it then entirely depends on your playback application if it can read this metadata and properly make use of it.

As far as I can seen, the resulting eac3to FLAC doesn't contain any metadata at all. Playback with MPC-HC and VLC sounds with a wrong layout.

Makemkv does, but the layout is wrong and it also ouputs an error message explaining why (FLAC doesn't support 3.1, makemkv writes a 4.0 layout).

Why can't FLAC support the layouts like HD audio ? Again some kitchentable developpers thinking their way is the best (based on the microsoft layout or what?) so this is a reason FLAC can't be compatible with some HD audio tracks (which ARE an insdustry standart) ???

So, it isn't possible to backup some HD tracks to FLAC.

For christ's sake...

WAV seems to be a much more complete format. With W64 eac3to writes the correct layout.

So the only choices seem to be:
1. W64, but there's no compression so its a huge file (wavpack still doesnt' support 4Gb files.... we are in 2015 dear Jesus!)
2. Keeping the DTS-HDMA....

What are the devs (xiph ?) waiting for to complete the FLAC format channel layouts properly? If WAV can, why can't FLAC do it?

Thanks for the feedback.

[nevcairiel]

Like I said, there is an informal spec for extra channel layout information, and a lot of tools support it just fine. Its not the formats fault if your tool or your workflow fail to use it.
Since madshi was one of the people that helped create this extra layout information, I'm sure eac3to can also handle it.

Edit:
In fact, I just tested, used a 3.1 DTS sample clip, converted it to FLAC with eac3to, and it set the appropriate metadata tag (ie. WAVEFORMATEXTENSIBLE_CHANNEL_MASK=0XF, which means front L/R, center, LFE)
Plays as 3.1 in MPC-HC, too, and MediaInfo reports the appropriate channel mapping for the FLAC file.

[Bigmango]

Like I said, there is an informal spec for extra channel layout information, and a lot of tools support it just fine. Its not the formats fault if your tool or your workflow fail to use it.

Why is it informal ? So hardware players and other players will never support it?

eac3to doesn't write channel layout metadata.

Makemkv does. Are there any other tools?


Since madshi was one of the people that helped create this extra layout information, I'm sure eac3to can also handle it.


There are several posts about such problems (also discussing why eac3to doesn't write channel layouts when makemkv does), and madshi always said writing channel layouts is useless. What he does with eac3to is moving the channel's around so that the layout matches the FLAC standard layouts when some tracks have a special layout.

And here the problem is that FLAc only has 4.0 (front left, front right, back left, back right). My DTSMA track is 3.1 (Front: L C R, Back: C), so it is not possible with FLAC. And the ffmpeg encoder in makemkv outputs an error to warn that the channels won't be layout properly.

As you are talking about my tool chain being bad, what other tools do you know of other than eac3to, makemkv and ffmpeg based tools that do work, as these don't?


Edit:
In fact, I just tested, used a 3.1 DTS sample clip, converted it to FLAC with eac3to, and it set the appropriate metadata tag (ie. WAVEFORMATEXTENSIBLE_CHANNEL_MASK=0XF, which means front L/R, center, LFE)
Plays as 3.1 in MPC-HC, too, and MediaInfo reports the appropriate channel mapping for the FLAC file.

My eac3to never writes channel layouts for FLAC and madshi said several times he won't do it with FLAC. Mediainfo shows no layout metadata. I'm using eac3to 3.29.

After converting this track with eac3to I can also clearly hear with MPC-HC that the channel mapping is wrong.

Why do you get channel mappings in mediainfo with eac3to when I don't, and when madshi said many times he won't do it? What am I missing?

Thanks.

[nevcairiel]

eac3to 3.29 just works for me, reading DTS 3.1 and writing FLAC. Can't tell you anything else. And I doubt that madshi said that he won't do it, as I know for a fact that he helped define this metadata for FLAC specifically.
Nothing magical, just "eac3to input.dts output.flac"

The only time it wouldn't write this metadata is when the layout matches the implicit FLAC layout anyway (ie. when its 4.0)

ffmpeg should also support this layout, at least reading it. Not sure if it can write it, but it might.

[DarkSpace]

A while back, I happened to try out ffmpeg's channel layouts, and I can tell for certain that (with a null source, because it was just a test) it added a WAVE_FORMAT_EXTENSIBLE tag to the output flac.
Further, I distinctly remember bugging nevcairiel (https://code.google.com/p/lavfilters/issues/detail?id=342) about these very tags that eac3to writes, so LAV Filters would honor them.

Edit: It may also have been a WAVEFORMATEXTENSIBLE tag, I don't remember for certain. What I do remember, though, is that it used the tag that signals a non-default channel layout.

Edit 2: Also, since it's in the changelog (https://xiph.org/flac/changelog.html#flac_1_1_3) ("Encoder can now take WAVEFORMATEXTENSIBLE WAVE files as input; decoder will output WAVEFORMATEXTENSIBLE WAVE files when necessary to conform to the latest Microsoft specifications."), it may even be more than just informal.

[Bigmango]

I tired again, here is the mediainfo output:

Source:

Audio
Format : DTS
Format/Info : Digital Theater Systems
Format profile : MA / Core
Mode : 16
Format settings, Endianness : Big
Bit rate mode : Variable
Bit rate : Unknown / 1 509 Kbps
Channel(s) : 4 channels
Channel positions : Front: L C R, Back: C
Sampling rate : 48.0 KHz
Bit depth : 24 bits
Compression mode : Lossless / Lossy


FFMPEG 2.7:
While encoding it shows this error in red: Channel layout not supported by Flac, output stream will have incorrect channel layout.
But it writes the layout tag fine.


Audio
Format : FLAC
Format/Info : Free Lossless Audio Codec
Duration : 2h 13mn
Bit rate mode : Variable
Bit rate : 2 604 Kbps
Channel(s) : 4 channels
Channel positions : Front: L C R, Back: C
Sampling rate : 48.0 KHz
Bit depth : 24 bits
Stream size : 2.42 GiB (100%)
Writing library : Lavf56.36.100


eac3to 3.29:
As I said, no channel layout metadata at all. As I understand, this means it will use 4.0, which is wrong.

Audio
Format : FLAC
Format/Info : Free Lossless Audio Codec
Duration : 2h 13mn
Bit rate mode : Variable
Bit rate : 2 612 Kbps
Channel(s) : 4 channels
Sampling rate : 48.0 KHz
Bit depth : 24 bits
Stream size : 2.43 GiB (100%)
Writing library : libFLAC 1.2.1 (UTC 2007-09-17)


VLC shows this in codec information:
DTSHDMA source: channels 3F1R
ffmpeg FLAC: channels 2F2R
eac3to FLAC: channels 2F2R

2F2R is FLAC 4.0, according to the FLAC format specs this is the only 4 channel layout supported.

[ndjamena]

Whatever version of VLC you're using is obviously buggy and doesn't read the tag yet. If the latest nightly can't read the layout tag you should report it on the bug tracker if it hasn't been done already.

What version of MediaInfo are you using? Old versions can't read layout tags with an uppercase 'X' in the hexidecimal value.

When MakeMKV complains about the layout, what is it actually saying? MakeMKV has been using the tags exclusively to denote layouts and has only learned to use the defaults for decoding since the latest release (thanks to madashi), but it does use FFMPEG internally for decoding and encoding FLAC. Is the error message from FFMPEG or MakeMKV itself? The layout is just a mask, as long as each channel position exists in the .wav layout specs you should be able to use any combination you like with impunity.

[madshi]

@Bigmango, first of all, please adjust your attitude. Belittling developers as "kitchentable developers" (no matter who you mean) is insulting. A bit more respect to devs who work their ass off to write software for you for free would look good on you.

Why is it informal ? So hardware players and other players will never support it?
Attitude, once again.

When FLAC was created, everybody used it for CD/Audio. Nobody used it for movies back then, because we only had DVD and there was no sense reencoding the DVD lossy tracks to FLAC. All this changed with Blu-Ray, which was released a loooong time after the FLAC spec was created. The original FLAC spec has a fixed channel speaker config for every channel number, but didn't have the option to define custom speaker defs. That was later added via metadata tag. This addition is not mentioned in the current spec, but it was confirmed to be "officially endorsed" by the FLAC dev. eac3to has been writing this metadata tag for many years now.

eac3to doesn't write channel layout metadata.
Flat out incorrect. eac3to does write channel layout metadata, but only if it's needed (which means if the default FLAC channel config differs from the actual channel config). Which means eac3to perfectly adapts to the FLAC spec.

My eac3to never writes channel layouts for FLAC and madshi said several times he won't do it with FLAC. Mediainfo shows no layout metadata.
Get your facts straight. I never said any such thing. If Mediainfo doesn't show layout metadata then that's a bug (or missing support for the channel config metadata) in Mediainfo.

I remember a similar problem was reported just a couple of pages ago in this very thread, and the user who complained ended up sending bug reports to the MediaInfo dev, which IIRC were accepted. So maybe just updating your MediaInfo version might already solve the issue (with MediaInfo). Not sure, but my memory tells me MediaInfo might have ignored the channel config metadata if it had the wrong case (lower case vs upper case letters), or something like that.

I don't know what decoders do or don't do with the FLAC channel config. Don't even remember if madFlac implements that properly. Seems LAV does, though, so try LAV.

[ndjamena]

I remember a similar problem was reported just a couple of pages ago in this very thread, and the user who complained ended up sending bug reports to the MediaInfo dev, which IIRC were accepted. So maybe just updating your MediaInfo version might already solve the issue (with MediaInfo). Not sure, but my memory tells me MediaInfo might have ignored the channel config metadata if it had the wrong case (lower case vs upper case letters), or something like that.


That bug was fixed, so the latest MediaInfo SHOULD read any WAVEFORMATEXTENSIBLE tag placed in a file correctly (unless there's some other oddity involved.)

FLAC defaults in MediaInfo are pending. I've been waiting almost 2 years for MediaInfo to report a DTS-ES core in DTS-HD so I don't know how long it will take to get FLAC defaults done. I've tried looking at the code but although it seems simple enough it's way beyond my skill level. I reported the same problem to MakeMKV and it was fixed within days, so for me at least MediaInfo is now the odd man out.

[Bigmango]

Many thanks to all of you people helping me out with this issue.

Whatever version of VLC you're using is obviously buggy and doesn't read the tag yet. If the latest nightly can't read the layout tag you should report it on the bug tracker if it hasn't been done already.

Ok, I'll have a look at the bug tracker and report it.


What version of MediaInfo are you using? Old versions can't read layout tags with an uppercase 'X' in the hexidecimal value.

Holly Jesus, I updated mediainfo and it now shows the tags for the eac3to FLAC. :D


When MakeMKV complains about the layout, what is it actually saying? MakeMKV has been using the tags exclusively to denote layouts and has only learned to use the defaults for decoding since the latest release (thanks to madashi), but it does use FFMPEG internally for decoding and encoding FLAC. Is the error message from FFMPEG or MakeMKV itself? The layout is just a mask, as long as each channel position exists in the .wav layout specs you should be able to use any combination you like with impunity.

Makemkv is spitting out an ffmpeg error line with the same error as when encoding with ffmpeg 2.7 directly (Channel layout not supported by Flac, output stream will have incorrect channel layout.), but continues its works and the resulting FLAC has a 4.0 channel layout with the default FLAC 2F2R channels for 4.0.

As ffmpeg 2.7 is writing the correct layout I am guessing 2 possible reasons for this:

either makemkv uses an older version of ffmpeg that doesn't work as version 2.7
or makemkv modifies the layout to write it by itself, this would be a makemkv bug?

[Bigmango]

When FLAC was created, everybody used it for CD/Audio. Nobody used it for movies back then, because we only had DVD and there was no sense reencoding the DVD lossy tracks to FLAC. All this changed with Blu-Ray, which was released a loooong time after the FLAC spec was created. The original FLAC spec has a fixed channel speaker config for every channel number, but didn't have the option to define custom speaker defs. That was later added via metadata tag. This addition is not mentioned in the current spec, but it was confirmed to be "officially endorsed" by the FLAC dev.

In the same way FLAC added the 6.1 layout with version 1.3, why don't they add these tags to the spec so all the players including hardware players can support complete channel layout properly, like the commercial HD codecs?

Today some older players still can't play the 6.1 channel files as they were made before the introduction of 6.1 in the spec. With these tags we would have the same issue of older players not playing back correctly. This problem doesn't seem to be an issue as we already had it with 6.1, so why don't they do it with the tags ? We would have an opensource 100% replacement for codecs like DTSHDMA.

Or at least they could add the 3.1 layout to the spec (as they did with 6.1).



eac3to has been writing this metadata tag for many years now.

Flat out incorrect. eac3to does write channel layout metadata, but only if it's needed (which means if the default FLAC channel config differs from the actual channel config). Which means eac3to perfectly adapts to the FLAC spec.

Get your facts straight. I never said any such thing.


There were several posts a few months earlier in this thread where people asked why eac3to didn't write the channel layout tags like makemkv, and you replied that FLAC was using the standard WAV layouts so there was no need to write the tags, and in case a track was using a strange setup you were moving the channels around with eac3to to match the default layout, so again you said there was no need to write the tags.

A few months ago prior to the new version mediainfo also didn't show any tags written by eac3to.

Perhaps what you said was all a misunderstanding then. Anyway I now see the tags with the new mediainfo, so all is well, thanks.


If Mediainfo doesn't show layout metadata then that's a bug (or missing support for the channel config metadata) in Mediainfo.

I remember a similar problem was reported just a couple of pages ago in this very thread, and the user who complained ended up sending bug reports to the MediaInfo dev, which IIRC were accepted. So maybe just updating your MediaInfo version might already solve the issue (with MediaInfo). Not sure, but my memory tells me MediaInfo might have ignored the channel config metadata if it had the wrong case (lower case vs upper case letters), or something like that.

I don't know what decoders do or don't do with the FLAC channel config. Don't even remember if madFlac implements that properly. Seems LAV does, though, so try LAV.

Yes, the new mediainfo sees the tags. :)

It would be so much better if FLAC just added these tags to the spec, as they did in version 1.3 with the 6.1 channel layout. So everyone could support this in the future.

:thanks:

[ndjamena]

I'll handle the MakeMKV FLAC bug, it seems to be my baby.

[Bigmango]

One more question:

As I understand, eac3to and ffmpeg are writing the channel layout tags differently.

This resulted in the problem with mediainfo only displaying the tags for ffmpeg FLAC and not for eac3to FLAC.

So, players and sofware now have to support 2 different ways of reading the tags. This means, as with mediainfo, we could get some players playing back correctly only some FLACs (i.ex made by ffmpeg) and not others (i.ex made by eac3to) if the developpers don't implement both different ways of reading the tags.

Can't the developers all follow the same way of writing the tags? Isn't this an unnecessary complication, leading to bugs as it happened with mediainfo?

(I guess this messy situation where everyone tries to implement his own way of doing things is one more result of the incomplete FLAC spec. What are the FLAC devs waiting for to add tags to the spec or at least the 3.1 channel layout ? (again: they did it for 6.1, why not 3.1))


I'll handle the MakeMKV FLAC bug, it seems to be my baby.

:thanks:

[ndjamena]

The prefix for hexadecimal numbers is '0x', I've only seen it in lower case, but apparently '0X' is acceptable too. It's not really a problem with the tags... I tend to think '0x' is correct but really hexadecimal is case insensitive so either should work fine in most programs. it's just MediaInfo was checking for an '0x' before it proceeded to interpret the tag and when it didn't find one it aborted. Most programs would just pass the hex number in full to a conversion function, which shouldn't care which case is used. (MakeMKV always uses '0x' yet it didn't flinch at the '0X prefix).

[madshi]

In the same way FLAC added the 6.1 layout with version 1.3, why don't they add these tags to the spec so all the players including hardware players can support complete channel layout properly, like the commercial HD codecs?
You'd have to ask the FLAC maintainers that.

Anyway, the metadata tag used by eac3to has been "known" for years. Actually at least 10 years, I've just checked. So there's nothing stopping players including hardware players from supporting it. But of course it would be better to mention this specific metadata tag directly in the FLAC spec. But nobody on doom9 has power over the FLAC spec, so if you want something changed there, you have to ask the FLAC guys about it, not us here.

There were several posts a few months earlier in this thread where people asked why eac3to didn't write the channel layout tags like makemkv, and you replied that FLAC was using the standard WAV layouts so there was no need to write the tags, and in case a track was using a strange setup you were moving the channels around with eac3to to match the default layout, so again you said there was no need to write the tags.
Nope, that is not a correct summary of what I said. eac3to writes the channel layout tag if it's needed (and only if it's needed). It has always done that.

Perhaps what you said was all a misunderstanding then. Anyway I now see the tags with the new mediainfo, so all is well, thanks.
If there was a misunderstanding, then it was on your part.

As I understand, eac3to and ffmpeg are writing the channel layout tags differently.
No. They write them exactly the same way, except that ffmpeg partially uses lower case letters while eac3to uses upper case letters. When reading text metadata (especially if it's a hexadecimal value as in this situation), upper/lower case should usually be ignored. mediainfo didn't do that, so it was a simple bug in mediainfo, which is fixed now, nothing more.

FYI, libav/ffmpeg just added support for the channel speaker metadata tag about a year ago. Probably mediainfo added support for it around the same time. eac3to has had support for this for 8 years now. Go figure.

[Bigmango]

@ madshi ok, thanks for the feedback.



Edit 2: Also, since it's in the changelog (https://xiph.org/flac/changelog.html#flac_1_1_3) ("Encoder can now take WAVEFORMATEXTENSIBLE WAVE files as input; decoder will output WAVEFORMATEXTENSIBLE WAVE files when necessary to conform to the latest Microsoft specifications."), it may even be more than just informal.

Hallelujah DarkSpace ! :thanks:

Yes, and even more so (FLAC 1.1.3 (27-Nov-2006) changelog):


Encoder can now take WAVEFORMATEXTENSIBLE WAVE files as input; decoder will output WAVEFORMATEXTENSIBLE WAVE files when necessary to conform to the latest Microsoft specifications.
Now properly supports AIFF and WAVEFORMATEXTENSIBLE multichannel input, performing necessary channel reordering both for encoding and decoding. WAVEFORMATEXTENSIBLE channel mask is also saved to a tag on encoding and restored on decoding for situations when there is no natural mapping to FLAC channel assignments.



So this seems to be a non-issue since FLAC 1.1.3 (27-Nov-2006).

But then why:

does ffmpeg output this error "Channel layout not supported by Flac, output stream will have incorrect channel layout" (and what are the consequences of this?)
does the latest MPC-HC 1.7.9 show in the file properties "A: flac, 48000 Hz, 4.0, s24" -> 4.0 when it should be 3.1
does makemkv convert the 3.1 3F1R DTSHDMA to 4.0 2F2R FLAC (writing these tags in the FLAC)
does VLC 2.2.1 in the properties show 4.0 2F2R instead of 3.1 3F1R


FLAC supports this since 2006, why don't these tools?

The problem seems to be that all the tools should read the WAVEFORMATEXTENSIBLE channel mask, but they don't ?

Is this because FLAC only wrote this in the 1.1.3 changelog, but they didn't add it to the online format spec, so the other tools aren't using this (some *but not all* do it informally as said above) ? If it is in the 1.1.3 changelog, why isn't it in the spec?

Summary: why is this a problem at all if it is supported by FLAC since 2006?

[ndjamena]

http://sourceforge.net/p/mediainfo/feature-requests/313/

2011-02-09

It was at least partially implemented since then.

These programs are all buggy/out of date. I don't know what MakeMKVs current problem is, it didn't even seem to know defaults existed a few weeks ago. I'll assume they just were overzealous with their implementation of "defaults". (What version are you using? Have you tried an older version?)

It's our job to get all these programs working, there's not much point in complaining about it here.

-edit- why do I get the feeling I'm on Madashis ignore list...

[madshi]

@ndjamena, sorry, I probably re-explained some things you had already covered. You're *not* on my ignore list.

@Bigmango. "3.1" is not correct. The correct name should be "3/1". At least that's how Dolby names it, and eac3to, too.

[Bigmango]

These programs are all buggy/out of date. I don't know what MakeMKVs current problem is, it didn't even seem to know defaults existed a few weeks ago. I'll assume they just were overzealous with their implementation of "defaults". (What version are you using? Have you tried an older version?)

I now made sure I am using the latest version of all the tools.


It's our job to get all these programs working, there's not point in complaining about it here.


I'm just asking to make sure I didn't miss something before talking about individual tool bugs specifically.

And since FLAC supports this since 2006, I can't imagine why all the tools don't support it in 2015. Who is the culprit? Who should fix this? Is it a bug in all of the tools, or is it a problem of FLAC writing something (WAVEFORMATEXTENSIBLE channel mask support) in the changelog without adding it to the format spec?

Thanks.

[Bigmango]

After playing back on my Yamaha receiver with the latest kodi (xbmc) 15 RC (uses a recent version of ffmpeg 2.6.x), here is the result:

(source DTS-HDMA 3/1)
(eac3to & ffmpeg FLAC : mediainfo shows correct 3/1 channel layout)

Track information on the Yamaha receiver:
DTS-HDMA source : channels 4.0 (3/1)
eac3to & ffmpeg FLAC : PCM channels 4.0 (2/2)

This means the latest ffmpeg versions write the channel layout tags correctly (as eac3to), but they don't play it back with the right channel layout.

This also means the eac3to 3/1 FLACs are not played back correctly, but eac3to doesn't issue any warning (as ffmpeg does when encoding "Channel layout not supported by Flac, output stream will have incorrect channel layout").

Shouldn't eac3to give a warning? And who should I write the bug report to (as per my above post, FLAC or all the tools (ffmpeg and all the tools not using ffmpeg like VLC)) ?

Thanks.

[Bigmango]

There seem to be too many problems with FLAC playback and non standard channel layouts (but then, DTS-HDMA is a standard, so can 3/1 DTS-HDMA layouts be considered as non-standard?).

Wavpack is currently adding 4+ Gb file support in the next version (which the dev said last february should be comming very soon).

2 questions considering the above:

is wavpack a good replacement for multichannel FLAC, especially when used with mkv. What about playback compatibility?
will eac3to add support for wavpack, especially considering the problems FLAC playback has with some channel layouts?


Thanks.

[ndjamena]

wavpack in MKV is completely useless. It has no channel layout at all. It's on the MKVToolNix bug tracker somewhere. MKVMerge will simply remove any layout info from the track because THERE IS NO WAY TO GIVE WAVPACK CHANNEL LAYOUTS IN AN MKV.

(and Mosu can't be bothered fixing that... PCM has no channel layout either, but the developer of MakeMKV went through hell to invent a codec to give it one.)

[Bigmango]

Thanks for the feedback ndjamena.

Then I'll keep the original DTS-HDMA track untill FLAC gets fixed.

Considering all of the above, why didn't FLAC go with WAVEFORMATEXTENSIBLE channel mask from the start instead of the current incomplete channel mappings.

FLAC really needs to add this to the format spec as it seems the tools will not support it without this even if it has been supported by FLAC for the past 10 years.

[nevcairiel]

But then why:

does the latest MPC-HC 1.7.9 show in the file properties "A: flac, 48000 Hz, 4.0, s24" -> 4.0 when it should be 3.1


3.1 would be 3 channels and a subwoofer. The dot notation does not split front and back channels like this.
If the file contains metadata, MPC-HC will play it properly.

[madshi]

After playing back on my Yamaha receiver with the latest kodi (xbmc) 15 RC (uses a recent version of ffmpeg 2.6.x), here is the result:

(source DTS-HDMA 3/1)
(eac3to & ffmpeg FLAC : mediainfo shows correct 3/1 channel layout)

Track information on the Yamaha receiver:
DTS-HDMA source : channels 4.0 (3/1)
eac3to & ffmpeg FLAC : PCM channels 4.0 (2/2)

This means the latest ffmpeg versions write the channel layout tags correctly (as eac3to), but they don't play it back with the right channel layout.

This also means the eac3to 3/1 FLACs are not played back correctly, but eac3to doesn't issue any warning (as ffmpeg does when encoding "Channel layout not supported by Flac, output stream will have incorrect channel layout").

Shouldn't eac3to give a warning?
eac3to's job is to produce a correct FLAC file, and that's what it does. So eac3to has no reason to warn about anything.

I don't know if HDMI supports 3/1 PCM transport. Maybe it doesn't? I've no idea. If it doesn't, then maybe 3/1 should simply be extended to 7.1 by adding empty channels? I don't know, and that's clearly outside of what this thread is about.

And who should I write the bug report to (as per my above post, FLAC or all the tools (ffmpeg and all the tools not using ffmpeg like VLC)) ?
Anyone but eac3to, because eac3to does things exactly right. If you find that other projects have bugs, complain to them.

I think at this point it's time to stop this discussion in this thread. This thread is about eac3to, and not about bugs in other projects like Kodi, ffmpeg, VLC, mediainfo or whatever.

[Bigmango]

Thanks for the feedback everyone.

eac3to's job is to produce a correct FLAC file, and that's what it does.

Yes of course. It can't do anything better with the broken/incomplete FLAC format specs (broken because incomplete).


So eac3to has no reason to warn about anything.

Ok. But the problem is that it writes files that will play back with a wrong channel layout for 3/1 (and what else? We don't know if other less used layouts will have problems as well as it doesn't give a warning with the bad player support for 3/1) with the majority of players (all commercial players, everything ffmpeg based, vlc,...).

According to the feedback above only the lav filters and perhaps MPC-HC will play the eac3to 3/1 correctly.

As this is a problem with the majority of players, this is imho an issue big enough to be worthy of a warning (ffmpeg decided it was as they added an error warning).


Anyone but eac3to, because eac3to does things exactly right. If you find that other projects have bugs, complain to them.

Ok.

I think at this point it's time to stop this discussion in this thread. This thread is about eac3to, and not about bugs in other projects like Kodi, ffmpeg, VLC, mediainfo or whatever.

Yes. But I think it was important to talk about this as the majority of players will not play back the 3/1 eac3to FLAC files correctly AND most users will never know this with no warning (and what else will be wrong in play back? we don't know as eac3to doesn't issue a warning as it does it in the best way it can with the current FLAC spec).

eac3to should tell users the FLAC spec is incomplete for this layout (and what about other layouts) and that playback problems may arise with many players.

If I hadn't tried encoding with makemkv and ffmpeg I would have never known there was a playback problem with my eac3to flac file.

[madshi]

I don't have the resources to test any and every funny format and speaker config. I suppose there will probably many more than 3/1 which may produce problems with some software or hardware players. And it won't be limited to FLAC, either. Warning about bugs in other software or hardware is not eac3to's job. The only thing I worry about is whether eac3to produces correct files. As long as it does, I'm satisfied. So instead of bugging me to add a warning, better spend your time getting the real bugs fixed in the other software/hardware. You're barking up the wrong tree here. It seems eac3to is one of the few parts of your tool collection which works correctly. So why do you bother *me* with change requests and complaints?

Btw, I think that using LAV Audio Decoder to decode eac3to's 3/1 FLAC files will probably produce the same results as playing 3/1 WAV files, or letting LAV Audio Decoder decode 3/1 DTS files in real time during playback. So I think this issue is not FLAC specific.

In any case, this is my last post about this topic.

[Bigmango]

Many thanks for the comprehensive feedback madshi.

I submitted bugs to ffmpeg #4698 (https://trac.ffmpeg.org/ticket/4698), VLC #15005 (https://trac.videolan.org/vlc/ticket/15005) and FLAC #430 (https://sourceforge.net/p/flac/bugs/430/).

We'll see what comes out of this. Hopefully FLAC will be a complete codec, one way or another.

[ndjamena]

We'll see what comes out of this. Hopefully FLAC will be a complete codec, one way or another.

Yup, FLAC will finally get out of the CD era and get a proper implementation of channel layouts... just as Dolby Atmos and DTS:X begin to render the whole thing obsolete. :scared:

[Mike Chen]

As ffmpeg 2.7 is writing the correct layout I am guessing 2 possible reasons for this:

either makemkv uses an older version of ffmpeg that doesn't work as version 2.7
or makemkv modifies the layout to write it by itself, this would be a makemkv bug?

As of now, MakeMKV uses libavcodec from ffmpeg 2.1 . I'll update the libs in next release.

[laz1989]

Hello guys,
After i read the eac3to tutorial, and even google it 100 times i didn't found a solution at this problem so i try to post here maybe someone will help me.
I have a Bluray with TrueHD and i want to extract the audio in 640 .ac3
With nero :

C:\Users\Desktop\eac3to>eac3to.exe D:\test.thd test.ac3 -nero
TrueHD, 5.1 channels, 48kHz
thd, 48000, 5.1
Disabling DRC for Nero (E-)AC3 decoding...
Decoding with DirectShow (Nero Audio Decoder 2)...
The DirectShow audio decoder didn't accept the input stream.
Aborted at file position 262144.

Whitout nero :

C:\Users\Desktop\eac3to>eac3to.exe D:\test.thd test.ac3
TrueHD, 5.1 channels, 48kHz
thd, 48000, 5.1
Decoding with libav/ffmpeg...
Remapping channels...
Encoding AC3 <640kbps> with libAften...
The libav decoder reported error -1094995529 while decoding.

And there it's the eac3to test.

C:\Users\Desktop\eac3to>eac3to -test
eac3to (v3.29) is up to date
Nero Audio Decoder (Nero 7) works fine
ArcSoft DTS Decoder (1.1.0.8) works fine
Sonic Audio Decoder (4.3.0.169) works fine
Haali Matroska Muxer (2013-04-14) is installed
There's a new version (2013-06-23) available
http://haali.net/mkv
Nero AAC Encoder (1.5.4.0) is up to date
Surcode DTS Encoder (1.0.29.0) is installed

IF someone can help me, i will be greatful.
Cheers!

[tebasuna51]

...
Decoding with libav/ffmpeg...
...
The libav decoder reported error -1094995529 while decoding.

Or your test.thd is corrupt or have some caracteristics not supported by libav decoder.

You can try with the last ffmpeg (http://ffmpeg.zeranoe.com/builds/) version:

ffmpeg.exe -i test.thd -acodec ac3 -ab 640k test.ac3

If still don't work and your test.thd play fine with some player you can upload a sample to ffmpeg developers.

[laz1989]

Thanks for your answer @tebasuna51.
Already try that before post here.

[truehd @ 04cb2d40] Lossless check failed - expected 13, calculated 1f.
[NULL @ 04caa440] mlpparse: Parity check failed.
[truehd @ 04cb2d40] Lossless check failed - expected 43, calculated 38.
[NULL @ 04caa440] mlpparse: Parity check failed.
[truehd @ 04cb2d40] Lossless check failed - expected 2a, calculated 1d.
[NULL @ 04caa440] mlpparse: Parity check failed.
[truehd @ 04cb2d40] Lossless check failed - expected c7, calculated 5f.
[NULL @ 04caa440] mlpparse: Parity check failed.
[truehd @ 04cb2d40] Lossless check failed - expected 9a, calculated 88.
[NULL @ 04caa440] mlpparse: Parity check failed.
[truehd @ 04cb2d40] Lossless check failed - expected 43, calculated d7.
[NULL @ 04caa440] mlpparse: Parity check failed.
[truehd @ 04cb2d40] Lossless check failed - expected 7f, calculated f9.
[NULL @ 04caa440] mlpparse: Parity check failed.
[truehd @ 04cb2d40] Lossless check failed - expected 6f, calculated 37.
[NULL @ 04caa440] mlpparse: Parity check failed.
[truehd @ 04cb2d40] Lossless check failed - expected dc, calculated a0.
[NULL @ 04caa440] mlpparse: Parity check failed.
[truehd @ 04cb2d40] Lossless check failed - expected 13, calculated d0.
[NULL @ 04caa440] mlpparse: Parity check failed.
[truehd @ 04cb2d40] Lossless check failed - expected 47, calculated 3b.
[NULL @ 04caa440] mlpparse: Parity check failed.
[truehd @ 04cb2d40] Lossless check failed - expected 8e, calculated 2a.
[NULL @ 04caa440] mlpparse: Parity check failed.
[truehd @ 04cb2d40] Lossless check failed - expected b6, calculated 81.
[NULL @ 04caa440] mlpparse: Parity check failed.
[truehd @ 04cb2d40] Lossless check failed - expected da, calculated 6a.
[NULL @ 04caa440] mlpparse: Parity check failed.
[truehd @ 04cb2d40] Lossless check failed - expected b7, calculated 7a.
[NULL @ 04caa440] mlpparse: Parity check failed.
[truehd @ 04cb2d40] Lossless check failed - expected 40, calculated e8.
[NULL @ 04caa440] mlpparse: Parity check failed.
[truehd @ 04cb2d40] Lossless check failed - expected 8c, calculated 7c.
[NULL @ 04caa440] mlpparse: Parity check failed.
[truehd @ 04cb2d40] Lossless check failed - expected 32, calculated 25.
[NULL @ 04caa440] mlpparse: Parity check failed.
[truehd @ 04cb2d40] Lossless check failed - expected c4, calculated f9.
[NULL @ 04caa440] mlpparse: Parity check failed.
[truehd @ 04cb2d40] Lossless check failed - expected 29, calculated 10.
[NULL @ 04caa440] mlpparse: Parity check failed.
Last message repeated 13 times
size= 31002kB time=00:06:38.80 bitrate= 636.8kbits/s
video:0kB audio:31002kB subtitle:0kB other streams:0kB global headers:0kB muxing
overhead: 0.000000%

And yes, the .thd it's not corrupt since it plays well different players.
I would wish more to find a problem to that nero encode since that seems the proper way to go from thd to ac3.

[sneaker_ger]

Is there any reason not to extract the core from the Blu-Ray? Free AC3 encoders don't have such a good reputation anyways.