eac3to - audio conversion tool

[tebasuna51]

Originally Posted by Music Fan

...A lossy compressed 24 bit file is bigger than a 16 bit lossy compressed file, which means there is difference in quantification, even if both are better decoded in 64 bits, right?
...
When you say "preserve the 64 bits", shouldn't you say preserve the "up-quantification" done by eac3to ?
Because if the original wave was in 16 bit, the decompressed file (coming from this wav) should keep its original quantification, otherwise there is big waste of space.

The 64 bits float is the better aproach to the original audio and if you want recode to another format you can use it, like eac3to do internally.

There is no sense store a wav file from a lossy format, if you decode to wav is for edit and after recompress, then preserve the best aproach you can manage until you recode to the desired format.

..(for a TS including ac3 @ 448 k, MediaInfo indicates 16 bits).

This is a wrong info from MediaInfo, don't belive all than MediaInfo say. Also for standard DTS most the times show 24 bits and is wrong.

[Music Fan]

Ok, but how is stored the quantification in lossy formats ? There is no quantification anymore ?
I don't understand this concept easily.

[microchip8]

Originally Posted by tebasuna51

This is a wrong info from MediaInfo, don't belive all than MediaInfo say. Also for standard DTS most the times show 24 bits and is wrong.

No, it's not wrong. The DD spec says max is 16 bits. If you want higher, like 24bit, only TrueHD/DD+ support that

[madshi]

Originally Posted by Music Fan

A lossy compressed 24 bit file is bigger than a 16 bit lossy compressed file

No, it's not. AFAIK, the first step of usual lossy encoders like AC3 or DTS is to convert the WAV to frequency domain (using FFT), which results in floating point numbers. The data is then compressed in the frequency domain. So basically the input bitdepth doesn't matter *at all*. Actually, a higher bitdepth input might actually improve the compression efficiency ever so slightly because it could have a lower noise floor and less quantization artifacts. Noise and quantization artifacts make life harder for the encoder.

Decoders do the opposite thing: They decompress the data, which is then still in frequency domain, and then convert back to time domain, which produces floating point data. So a lossy decoder natively outputs 64bit floating point.

[bennynihon]

How does one show the stdout when piping the output to a second audio encoder? I do something like this:

eac3to I: 1) 2: video.mkv 3: audio.ac3 3: stdout.wav -downDpl | D:\Apps\qaac\qaac -V 32 --ignorelength -o audio.m4a -

But that prevents me from seeing the progress of eac3to.

[bennynihon]

Does eac3to have a hard limit of being able to read just 300 playlists from a disc? The Redbox version of the Divergent Blu-ray has hundreds of playlists and despite other tools like MakeMKV detecting them all, eac3to stops at 300). This is a problem, since playlist 810.mpls is the correct one.

UPDATE: Disregard. The .mpls was 810, but I see that eac3to simply enumerates them sequentially

[Music Fan]

Originally Posted by madshi

No, it's not. AFAIK, the first step of usual lossy encoders like AC3 or DTS is to convert the WAV to frequency domain (using FFT), which results in floating point numbers. The data is then compressed in the frequency domain. So basically the input bitdepth doesn't matter *at all*. Actually, a higher bitdepth input might actually improve the compression efficiency ever so slightly because it could have a lower noise floor and less quantization artifacts. Noise and quantization artifacts make life harder for the encoder.

Decoders do the opposite thing: They decompress the data, which is then still in frequency domain, and then convert back to time domain, which produces floating point data. So a lossy decoder natively outputs 64bit floating point.

Interesting.
Does it mean there is less differences between dts 16 bits and dts 24 bits than between pcm 16 bits and pcm 24 bits ?
Despite the fact that the input bitdepth doesn't matter at all, is there a way to evaluate the quality (or the corresponding bitdepth) of a lossy compressed file ?

[LigH]

What do you mean by "dts 16 bits" and "dts 24 bits"?

As just explained, most compressed formats don't save "samples" (the volume at discrete moments of time), but instead a limited sound spectrum over brief durations. The less precision the original audio had, if it was stored as integer samples, the harder this lack of precision can be transformed into a sound spectrum; imagine it like laying a smooth but slightly stiff carpet over a stairway with stairs of different heights, just the same depth. The compressed format saves the curves in the shape of the carpet. You can have the same shape of carpet laying over different kinds of stairs, with more or less distance of the stair edges to the carpet shape...

The "quality" of the encode may represent the distance of the carpet shape to the edges of the original staircase. If you don't have the staircase available anymore, you can't judge how good the carpet once fit it when it was bent over it with more or less pressure.

Decoding means building a new staircase which fits under the carpet. You can do that with more or less precision, but only compared to the carpet shape, not to the original staircase.

[Music Fan]

Ok, thanks.

Originally Posted by LigH

What do you mean by "dts 16 bits" and "dts 24 bits"?

dts is supposed to exist in several levels of quality, I guess you have heard of dts 96/24 (while generally dts is supposed to be 48/16 or 48/20), but now I understand that this only concerns the accepted input formats for the dts encoder (however, one can see the dts 96/24 logo on some dvd's).

[LigH]

In case of DVD Video, dts Coherent Acoustics was primarily supposed to reduce 6-channel 16 bit PCM to the bitrate of mono or stereo 16 bit PCM, because S/P-DIF is not able to submit higher bitrates than the one of 48 kHz 16 bit stereo (1536 kbps) to A/V receivers. Similar goals will have been used for "dts Audio CDs", to stay below the bitrate of 44.1 kHz 16 bit stereo (1411.2 kbps) but support multi-channel audio.

More precise dts variants are possibly extensions to the "core" format.

But in any case, it doesn't mean that 16 or 24 bit samples are stored inside the compressed audio, just that the encoding is precise enough to reproduce up to 16 or 24 bits of precision when decoded to PCM again and compared to the original. I would believe that in "best cases". In complex cases (like hardrock), precision may drop by a few bits, but won't be noticable due to psychoacoustic effects.

[Music Fan]

Ok.
I'm astonished you consider hardrock as a complex case, I believed it was simpler than classical music which contains a lot of frequencies and harmonics.
Or you mean it is more complex because of its higher dynamic compression (which is often the case in hardrock), which makes instruments more difficult to detach from each other ?

[LigH]

Classical music is often easier to compress due to a quite restricted spectrum, having mostly clean sounds based on a few dominating tones with harmonics. Most audio compression algorithms (except Opus) can handle simple tones and sounds with only few harmonics quite easily.

In contrast, especially the sound of overdriven electro guitars is much closer to "noise" than to "sound", it is quite hard to predict for common audio compression.

[tebasuna51]

Originally Posted by froggy1

No, it's not wrong. The DD spec says max is 16 bits. If you want higher, like 24bit, only TrueHD/DD+ support that

I read in DD docs than the samples in frequency domain have a precission equivalent to a bitdepth of 20 bits.

The question here is not the bitdepth (16, 20 or 24) but in the word equivalent, when the user read this info can wrong supose than the decoded output have a precission of 16/24 bits and that is not true, the precission is always less than 16 bits in lossy formats.

Originally Posted by Music Fan

Interesting.
Does it mean there is less differences between dts 16 bits and dts 24 bits than between pcm 16 bits and pcm 24 bits ?
Despite the fact that the input bitdepth doesn't matter at all, is there a way to evaluate the quality (or the corresponding bitdepth) of a lossy compressed file ?

The unique measure of quality of a lossy compressed file is the bitrate and the compressor efficiency.

A DTS have in the header a bitdepth info of the original PCM source (not always true, some Surcode versions put always 24 even if the source is 16 bits), of course the compressed file can be better if the source have a better precission, but, like I say before, associate a bitdepth info to a lossy format only mistake the users like you can see in this discussion.

[microchip8]

Originally Posted by tebasuna51

I read in DD docs than the samples in frequency domain have a precission equivalent to a bitdepth of 20 bits.

The question here is not the bitdepth (16, 20 or 24) but in the word equivalent, when the user read this info can wrong supose than the decoded output have a precission of 16/24 bits and that is not true, the precission is always less than 16 bits in lossy formats.

From what I understand, lossy format (don't know if all, but at least for MP3) use FP math to build their output values. From this, there is no true or correct bit depth. So, it is virtually impossible for MediaInfo to correctly identify the bit depth, but it can only estimate it

[SeeMoreDigital]

Originally Posted by Music Fan

dts is supposed to exist in several levels of quality, I guess you have heard of dts 96/24 (while generally dts is supposed to be 48/16 or 48/20), but now I understand that this only concerns the accepted input formats for the dts encoder (however, one can see the dts 96/24 logo on some dvd's).

And when you play DTS 96/24 sources through a (supporting) surround sound amplifier you'll even see a dedicated 'DTS 96/24' icon light up... It's meaningless marketing pap!

Mathematically a 96/24 DTS file size should be much larger than a 48/16 DTS file size... But they're the same!

[bennynihon]

Originally Posted by bennynihon

How does one show the stdout when piping the output to a second audio encoder? I do something like this:

eac3to I: 1) 2: video.mkv 3: audio.ac3 3: stdout.wav -downDpl | D:\Apps\qaac\qaac -V 32 --ignorelength -o audio.m4a -

But that prevents me from seeing the progress of eac3to.

I know tee in Unix/Linux does something similar, but usually it's used to log the stdout and still see it as it progresses on the screen. Tried using the GNUWin32 version of tee and for some reason it doesn't work, even though from what I read this should both display stdout and pipe it to the next command (con being the Windows equivalent of /dev/tty)

eac3to title.mkv 1: video.mkv 2: audio.ac3 2: stdout.wav -downDpl | tee con | D:\Apps\qaac\qaac -V 32 --ignorelength -o audio.m4a -

How can I display progress while piping stdout to another encoder?

[LigH]

There are three common ways to create text output on the console:

a) STDOUT = file descriptor 1, redirectable via '>' and '|'
b) STDERR = file descriptor 2, redirectable via '2>'
c) direct video memory access, not redirectable (for those who used Turbo Pascal: when using unit CRT)

I wouldn't know without testing which output technique eac3to prefers for its usual progress reports while writing to a file. If it is STDOUT, then it will possibly suppress the progress output completely while piping?

[jpsdr]

I think eac3to is in Delphi. It's not Turbo Pascal, but...

[Music Fan]

Originally Posted by tebasuna51

I read in DD docs than the samples in frequency domain have a precission equivalent to a bitdepth of 20 bits.

That seems contradictory with this ;

Originally Posted by tebasuna51

the precission is always less than 16 bits in lossy formats.

Originally Posted by tebasuna51

the compressed file can be better if the source have a better precission

Does it mean the DD docs is wrong ?
And thus, why encode from 24 bits sources ?

Originally Posted by tebasuna51

The unique measure of quality of a lossy compressed file is the bitrate and the compressor efficiency.

And sample frequency, right ?

[tebasuna51]

Originally Posted by Music Fan

Does it mean the DD docs is wrong?

For what? The samples in frequency domain are stored with a precission equivalent but when recover the samples in time domain don't exist the precission of the source. For that is lossy compression and not lossless.

And thus, why encode from 24 bits sources?

I say because the samples in frequency domain are better calculated with a source more precisse.

And sample frequency, right?

Right, but when there aren't enough bitrate to store all frequency samples the high frequencies are sacrified.