eac3to - audio conversion tool

[tebasuna51]

When I transcode audio to FLAC...
What are the defaults for each and every channel count?

http://forum.doom9.org/showthread.php?p=1718489#post1718489

[Xor]

Hybrid (which uses Sox for audio changes) ;
http://forum.doom9.org/showthread.php?t=153035
You have the choice between fps and duration (specify original and destination) and you can change the pitch or not, very convenient.

Thanks

[Furiousflea]

http://forum.doom9.org/showthread.php?p=1718489#post1718489

Interesting you post this.

Does eac3to apply a custom channel mask automatically if say encoding 3/1 (4 channel track with 3 channels at the front, 1 at the rear)

I ask because eac3to detects the track correctly and states "3/1" before demuxing, but when encoding mediainfo reports left/right/rear left/rear right...

...Or is end user expected to input mask regardless?

Thanks, I know this kind of thing has been mentioned countless times before, but it never seems to get answered with any certainty.

[ndjamena]

http://forum.doom9.org/showthread.php?p=1718489#post1718489

OK, I guess that leaves the question: What is MakeMKV doing differently that the Channel Layout is shown by MediaInfo... And how can I add that info to an eac3to FLAC encode after encoding?

[tebasuna51]

I ask because eac3to detects the track correctly and states "3/1" before demuxing, but when encoding mediainfo reports left/right/rear left/rear right....

And how can I add that info to an eac3to FLAC encode after encoding?

Same answer for both: eac3to work fine, maybe MediaInfo is not perfect.

eac3to v3.29 command line: eac3to 4w310.wav 4w310.flac
------------------------------------------------------
WAV, 3/1 channels, 0:00:20, 16 bits, 3072kbps, 48kHz
Reading WAV...
Creating file "D:\tmp\4w310.flac"...

eac3to v3.29 command line: eac3to 4w310.flac
------------------------------------------------------
FLAC, 3/1 channels, 0:00:20, 16 bits, 202kbps, 48kHz

Flac identified correctly and played fine by MPC-HC like FL FR FC BC.
MediaInfo don't say nothing about Channel Layout.

eac3to v3.29 command line: eac3to 4w220.wav 4w220.flac
------------------------------------------------------
WAV, 2/2 channels, 0:00:20, 16 bits, 3072kbps, 48kHz
Reading WAV...
Creating file "D:\tmp\4w220.flac"...

eac3to v3.29 command line: eac3to 4w220.flac
------------------------------------------------------
FLAC, 2/2 channels, 0:00:20, 16 bits, 205kbps, 48kHz

Flac identified correctly and played fine by MPC-HC like FL FR SL SR.
MediaInfo don't say nothing about Channel Layout.

[ndjamena]

-Edit- Nevermind, Visual Studio seems to accept 0X as a hex prefix...

Um, I've only ever seen 0x used as a Hex prefix, does anyone know who sets the standards and whether the case of the 'x/X' is supposed to matter? ie 0x vs. 0X

[ndjamena]

Fixed :)

http://forum.doom9.org/showpost.php?p=1719488&postcount=1376

(For one program at least.)

[tebasuna51]

Off topic Xor post moved to http://forum.doom9.org/showthread.php?t=172085

[Furiousflea]

Thanks tebasuna51 for clearing that niggling doubt up once and for all, much appreciated :)

[Atak_Snajpera]

Is it possible to decode only specific channel with eac3to? I've checked this site http://en.wikibooks.org/wiki/Eac3to/How_to_Use and haven't found anything.

[tebasuna51]

You can decode to multiple wavs, not only one channel:
output.file ~ This is the output file that eac3to will create. It could be an audio format like RAW, (L)PCM, WAV (PCM only), WAVs (multiple mono WAV files, PCM only),...

eac3to input output.wavs

[Atak_Snajpera]

But what if I want to pipe just one channel?

something like this
eac3to.exe some.flac stdout.wav -channel 0 | lossywav.exe | flac.exe

[tebasuna51]

It's not possible, there are the remap parameter -0,4,5,1,2,3 but is ignored when there are less channels than input.

Maybe you can filter the channels with sox.

[nautilus7]

You can decode/save only center channel using "-mono" and ".wavs" as output format.

[ndjamena]

Another FLAC file MediaInfo can't detect the channel layout of.

This one doesn't seem to have that Layout MetaData Tag in it though, which I assume means it "defaults" to what's on that table.

It's source is 5.1 True HD with a layout of - Front: L C R, Side: L R, LFE - which would make it 5.1(side) yet unless I'm reading it wrong the table indicates 6 channels should be 5.1(back)

https://xiph.org/flac/format.html#def_STREAMINFO

◦6 channels: front left, front right, front centre, LFE, back/surround left, back/surround right

FFMPEG is detecting it as 5.1(side), are they the same thing? The terminology is confusing. What am I missing?

[ndjamena]

Anyway, I grabbed the 5.1(side) layout Hex Value from a MakeMKV encode (0x60F), and used MP3Tag to add the WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag to the file in the abundance of space EAC3To leaves in it's forward headers.

Now I finally have a copy of The Matrix with it's actual 16 bit audio while still displaying channel layout in MediaInfo. Reloaded and Revolutions are next, then when MakeMKV fixes its surround sound FLAC decoding I'll remux the MKV while re-encoding the FLAC and no one will ever know it wasn't encoded straight from the original 24 bit TrueHD track.

I'm going to have to go back and fix all the other FLAC tracks I did with EAC3To eventually...

[madshi]

There is nothing to "fix" in eac3to created FLAC files. eac3to automatically writes the WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag when it's needed, and doesn't write it when it's not needed. The tag is not needed when the channel mask matches the FLAC default channel mask. As far as I can see, any software which doesn't handle the channel mask of eac3to created FLAC files correctly has to be considered buggy.

[ndjamena]

Yes, MediaInfo IS buggy, I don't need to be told that. However, my batches and a lot of other programs use it and so far every EAC3To encode has buggered up my audio naming scripts.

I don't know what to tell Jerome and so far no one has told me what's going on, he does expect me to know something about the bug I'm reporting, or at least someone too.

Tebasuna51's link and the FLAC webpage seem to be saying the default is 5.1(back) not 5.1(side), is there another way of stating layout somewhere that I'm missing? Tell me what I need to know and I'll tell Jerome otherwise I'll fix it however I can until a better way comes along.

(MediaInfo may not be the only program with this problem, so it can't hurt to mention the solution, although a world where every program was perfect would be nice.)

[madshi]

There has been a history of confusion with 5.1 channel assignments. In theory there's a difference between 5.1(back) and 5.1(side), but in real life there really isn't. Old Windows versions used channelmask 0x3F, which is 5.1(back), newer versions are using 0x60F, which is 5.1(side). Practically, when transporting this kind of data as 5.1 via HDMI to the receiver, it ends up all the same. The FLAC spec says that the default channel order for 5.1 is "5.1(back/side)". Well, it's described in other words, but you get my meaning: The FLAC spec doesn't make a difference between side and back for 5.1 channels. And neither does eac3to. The correct format is 5.1(side). And the only proper way to handle 5.1(back) is to treat it as 5.1(side), as well.

I don't know what problem MediaInfo might have, I don't use it. Fact is, if WAVEFORMATEXTENSIBLE_CHANNEL_MASK is specified, that's the channel assignment you should use. If that WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag is missing, then the default FLAC channel assignment should be used. On the following page search for "6 channels:" to see a list of the FLAC default channel assignments:

https://xiph.org/flac/format.html

[tebasuna51]

The fisrt M$ spec about 5.1 was FL,FR,FC,LF,BL,BR (back, mask 0x003F) and match the AC3 5.1 layout L,C,R,SurroundL,SurroundR,LFE or the DTS layout C,L,R,Ls,Rs,LFE

When come the 7.1 channels FL,FR,FC,LF,BL,BR,SL,SR (back, side, mask 0x063F) the M$ 5.1 specs change (if I remember whit M$ XP) to prefer FL,FR,FC,LF,SL,SR (side, mask 0x060F) over the old FL,FR,FC,LF,BL,BR but both specs remain valid, for backward compatibility, and any players must play the same with mask 0x003F or 0x060F.

Then, in a 5.1 layout, the last channels can be named Back, Side or simple Surround at your choice. That means the FLAC back/surround channels.

Only the 6.1 layout can be problematic because in the old M$ style FL,FR,FC,LF,BL,BR,BC (0x013F) the last channels don't have the same order than the new FL,FR,FC,LF,BC,SL,SR (0x070F), then here is important the correct channel-mask and order.
Any updated soft, like eac3to, must use FL,FR,FC,LF,BC,SL,SR (0x070F) and here FLAC is clear:
7 channels: front left, front right, front center, LFE, back center, side left, side right

EDIT: I don't see the madshi reply

[torturesauce]

dcadec still cannot play 20-bit DTS files (frequently found on DTS-CD's), and whenever I play them in foobar, they sound garbled and sped-up. Arcsoft is still the solution; it patches the bitdepth to 24 bits and converts the file to WAV/FLAC so you can listen to it with foobar. Just thought I should point this out.

[nevcairiel]

dcadec still cannot play 20-bit DTS files (frequently found on DTS-CD's), and whenever I play them in foobar, they sound garbled and sped-up. Arcsoft is still the solution; it patches the bitdepth to 24 bits and converts the file to WAV/FLAC so you can listen to it with foobar. Just thought I should point this out.

Please provide a sample file, then we can tell the author and make it work.

[tebasuna51]

dcadec still cannot play 20-bit DTS files (frequently found on DTS-CD's), and whenever I play them in foobar, they sound garbled and sped-up. Arcsoft is still the solution; it patches the bitdepth to 24 bits and converts the file to WAV/FLAC so you can listen to it with foobar. Just thought I should point this out.

Don't exist such "20-bit DTS files" and ArcSoft can't "patches the bitdepth to 24 bits" because a standard DTS don't have bitdepth.

Seems you mistake a DTSWAV from a DTS-CD with that.

A DTSWAV have a fake WAV header like a PCM stereo 16 bits 44100 samplerate to be accepted to burn a CD, but the data is a special DTS stream 5.1.

Is special because the 2 most significant bits of each WORD (16 bits) are set to '0', to avoid speakers damage in players than not recognize this format and try to play this WAV like a standard WAV PCM.

The WORD's in the special DTS data in the stream use only 14 bits Little-Endian and not 16 bits Big-Endian like a standard DTS.

You can create a DTSWAV from 6 source mono WAV's PCM 44100 Hz with DTS Master Audio.

Also with a source 5.1 WAV PCM 44100 Hz and ffdcaenc:
ffdcaenc -e -r -i source.wav -o output.dts -b 1411.2

you can create the DTS 14 bits Little-Endian, and to obtain the DTSWAV:
wavfix output.dts DTSWAV.wav -s 44100

Here is a Channel test sample: https://www.sendspace.com/file/dws3gx

EDIT:
To convert a DTSWAV.WAV to a standard DTS 16 bits Big-Endian you can use the old BeSplit:
BeSplit -core( -input "DTSWAV.wav" -prefix "x" -type dtswav -fix )

[Thunderbolt8]

but 20-bit DTS-HD MA tracks are decoded perfectly with dcadec? (those 24-bit tracks which only have 20-bit of real data and the rest is empty)

[nevcairiel]

They should be fine. If you have anything that doesn't decode properly, just report them, and it'll get fixed. If you just assume its broken for some reason and never give us or the developer of dcadec a chance to check it out (say, by providing a sample), its not going to get any better either.

[Furiousflea]

Yes, MediaInfo IS buggy, I don't need to be told that. However, my batches and a lot of other programs use it and so far every EAC3To encode has buggered up my audio naming scripts.

I don't know what to tell Jerome and so far no one has told me what's going on, he does expect me to know something about the bug I'm reporting, or at least someone too.

Tebasuna51's link and the FLAC webpage seem to be saying the default is 5.1(back) not 5.1(side), is there another way of stating layout somewhere that I'm missing? Tell me what I need to know and I'll tell Jerome otherwise I'll fix it however I can until a better way comes along.

(MediaInfo may not be the only program with this problem, so it can't hurt to mention the solution, although a world where every program was perfect would be nice.)

Mediainfo isn't buggy.
Media info is technically correct. It's a software to tell you specification of a file, that's what it's supposed to do. The issue isn't with Mediainfo.
eac3to is practically correct and technically wrong, but only by definition, not in any actual usage scenario.
So all are correct, none are buggy.

The "issue" is one of definition, a definition that is never practically exploited and an uncorractable legacy without new standards.
Why would new standards be created to "fix" a legacy issue that has no practical downside? :)

FLAC spec can't hold side/back channel info, it's all "back".
No player plays "back" as "back" unless there is a "side".
If there is a "side" then "back" will be correct, if there isn't, it will still be correct becasuse it will be played as side.

...Blame Dolby if anyone and their stupid 90s marketing where they insisted side=back.

[ndjamena]

Um, MediaInfo reports NO Layout if it's not specifically mentioned in a WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag, which is apparently not how the FLAC specifications work. That's a bug.

The whole 5.1 side/back thing was just me trying to clarify how it's supposed to work so I could properly report it...

http://forum.doom9.org/showthread.php?p=1718489#post1718489

Tebasuna51 seems to like using the old 5.1(back) numbers (0x003F), whereas there's a new number for 5.1(side) (0x60F). Add to that the ambiguity of the FLAC naming ( back/surround left, back/surround right) and I was confused.

[tebasuna51]

...
Tebasuna51 seems to like using the old 5.1(back) numbers (0x003F), whereas there's a new number for 5.1(side) (0x60F). Add to that the ambiguity of the FLAC naming ( back/surround left, back/surround right) and I was confused.

Read also my post http://forum.doom9.org/showthread.php?p=1720161#post1720161
"... the M$ 5.1 specs change (if I remember whit M$ XP) to prefer FL,FR,FC,LF,SL,SR (side, mask 0x060F) over the old FL,FR,FC,LF,BL,BR but both specs remain valid, for backward compatibility, and any players must play the same with mask 0x003F or 0x060F."

The Surround channels in AC3 or DTS 5.1 are at +-120º from front, the Side channels in WAV are at 90º-110º and Back at 130º-150º, none are exact and both can be used, don't make a problem with this.

[ndjamena]

MediaInfos bug relating to the reading of hex values with uppercase 'X's in the WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag has already been fixed and will be included in the next release.

MediaInfos bug in relation to default channel mapping in FLAC has been acknowledged and will most likely be fixed in the next release as well.

At that point MediaInfo and EAC3To will be fully cross compatible in regards to FLAC channel layouts, and you'll never hear about it again.

[tebasuna51]

@jriker1
What is your question?

Now the libDcaDec is the default DTS 7.1 decoder, your log is ok.

[r0lZ]

I have read this in an old post from October 2008:
NOTE:Some Blu-ray disks which have playlists containing multiple m2ts files carry audio ovarlaps/gaps.
If this audio file is a TrueHD, this can't be corrected by eac3to. In this case truehd must be converted to pcm or flac.
Is it still true, or is eac3to able to process the overlaps in BD THD+AC3 streams correctly now?

I wonder also if tsMuxeR has the same problem when it demuxes the THD track from a multi-M2TS playlist?
In the tsMuxeR log, I see messages like this one:

TRUE-HD stream (track 3): overlapped frame detected at position 00:04:15,391. Remove frame.

It seems therefore that tsMuxeR can remove the overlaps, but I note that the message is printed only once, and I don't know if it refers to the THD or the AC3 core, or both.

And can I assume that the overlaps are removed properly by the two programs if only the 5.1 AC3 core is extracted from the THD+AC3 BD stream?

[tebasuna51]

stax76 post and answers moved to a new trhead: http://forum.doom9.org/showthread.php?t=172144

[Xor]

how to join two ac3?

I try this command:

eac3to cd1.ac3+cd2.ac3 joined.ac3 -448
and
eac3to cd1.ac3 + cd2.ac3 joined.ac3 -448

but receive error: The format of the source file could not be detected

[Boulder]

You don't need eac3to for that. You can use the command copy /B cd1.ac3+cd2.ac3 joined.ac3 .

[Xor]

You don't need eac3to for that. You can use the command copy /B cd1.ac3+cd2.ac3 joined.ac3 .

Thanks, work fine

[Xor]

Please help me, this command not work, why?

eac3to.exe "AUDIO25.ac3" "AUDIO23976.ac3" -25.000 -changeTo23.976
The format of the source file could not be detected

[LigH]

Are you really really sure it is AC3?

Can MediaInfo confirm that?

[tebasuna51]

If ac3 was extracted from a .avi maybe have initial garbage (fake delay used with avi's), you need first fix the ac3 with DelayCut for instance.

[DoctorM]

Please help me, this command not work, why?

eac3to.exe "AUDIO25.ac3" "AUDIO23976.ac3" -25.000 -changeTo23.976
The format of the source file could not be detected

Do you want -changeto23.976 or do you mean -Slowdown?

[tebasuna51]

Do you want -changeto23.976 or do you mean -Slowdown?

-slowdown and -25.000 -changeTo23.976 is the same.

eac3to.exe "AUDIO25.ac3" "AUDIO23976.ac3" -25.000 -changeTo23.976

is correct sintax, and also this one:

eac3to cd1.ac3+cd2.ac3 joined.ac3 -448

without spaces between sources (cd1 and cd2 must have the same samplerate, bitrate and num_channels. Also without initial garbage).

[Boulder]

and also this one:

eac3to cd1.ac3+cd2.ac3 joined.ac3 -448

without spaces between sources (cd1 and cd2 must have the same samplerate, bitrate and num_channels. Also without initial garbage).But in this case, eac3to re-encodes while a normal copy does not.

[stax76]

might this be a bug?

eac3to v3.29
command line: "C:\Program Files\Staxrip\Apps\eac3to\eac3to.exe" "F:\Neuer Ordner (2)\ID3 German.thd" "F:\Neuer Ordner (2)\ID3 German_out.ac3" -448 -normalize -progressnumbers
------------------------------------------------------------------------------
TrueHD, 5.1 channels, 48kHz
thd, 48000, 5.1
Decoding with libav/ffmpeg...
Writing WAV...
Creating file "F:\Neuer Ordner (2)\ID3 test_out.ac3.pass1.wav"...
Original audio track: max 24 bits, average 20 bits, most common 20 bits.
Caution: The WAV file is bigger than 4GB. <WARNING>
Some WAV readers might not be able to handle this file correctly. <WARNING>
Starting 2nd pass...
Reading WAV...
Remapping channels...
Encoding AC3 <448kbps> with libAften...
Applying -0.07dB gain...
Creating file "F:\Neuer Ordner (2)\ID3 test_out.ac3"...
The processed audio track has a constant bit depth of 64 bits.
eac3to processing took 4 minutes, 39 seconds.
Done.

[tebasuna51]

might this be a bug?

Maybe, I can't understand how a thd lossless decoder (libav/ffmpeg) can ouput a value at +0.07dB, than need the:
Applying -0.07dB gain...

The <WARNING>'s are ok.

[Boulder]

I've seen those very small adjustments many times with both TrueHD and DTS-HD MA tracks. I don't know what eac3to considers to be clipping but those ones never trigger that notification so you only see them when you use normalize.

[tebasuna51]

I've seen those very small adjustments many times with both TrueHD and DTS-HD MA tracks. I don't know what eac3to considers to be clipping but those ones never trigger that notification so you only see them when you use normalize.

You are right, I don't see the -normalize parameter (not recommended with lossless tracks).

[LigH]

I believe that psychoacoustics might sometimes remove frequencies in a way that their loss causes a slight amplification, because their phase was negative thus limiting in rare cases.

[GCRaistlin]

Why do the result files differ for
eac3to file.ac3 file1.ac3 +96ms
and
eac3to file.ac3 file2.ac3 -edit=0:00:00,+96ms -silence
(file2.ac3 is 1 sample shorter than file1.ac3)?

[LigH]

1 sample? Isn't AC3 stored in audio blocks of 32 ms each?

[GCRaistlin]

That's what I mean. file2.ac3 is shifted by 32 ms.

[tebasuna51]

file2 is a frame (32 ms) shorter than file1, then use always +96ms only.

BTW, the first logic use of edit:

-edit=0:00:00.032,+96ms

works fine.