eac3to - audio conversion tool

[Boulder]

Yes, I can confirm than LFE decoded with Arcsoft 1.1.0.0 is 3 dB louder than the LFE channel decoded with Foobar2000 decoder or with the AviSynth NicAudio decoder.Does that mean that the Sonic decoder is actually the preferred one if you don't have a 7.1ch file to decode?

[Frozen Fractals]

I am getting an error when extracting a TrueHD stream. Error states that the "lossless check failed." However, the process completes itself regardless of the error and I get 8 individual wave PCM files (corresponding to each channel)...but, I am unsure of the integrity of the resulting wave PCM files. Log posted below.

C:\Program Files (x86)\eac3to>eac3to.exe E:\Audio\Brave\Brave.mka E:\Audio\Brave
\Brave_pcm.wavs
MKA, 1 audio track, 1:33:37
1: TrueHD, English, 7.1 channels, 48kHz
Track 1 is used for destination file "Brave_pcm.wavs".
a01 Extracting audio track number 1...
a01 Decoding with libav/ffmpeg...
a01 Writing WAVs...
a01 Creating file "E:\Audio\Brave\Brave_pcm.SL.wav"...
a01 Creating file "E:\Audio\Brave\Brave_pcm.BR.wav"...
a01 Creating file "E:\Audio\Brave\Brave_pcm.SR.wav"...
a01 Creating file "E:\Audio\Brave\Brave_pcm.L.wav"...
a01 Creating file "E:\Audio\Brave\Brave_pcm.BL.wav"...
a01 Creating file "E:\Audio\Brave\Brave_pcm.C.wav"...
a01 Creating file "E:\Audio\Brave\Brave_pcm.LFE.wav"...
a01 Creating file "E:\Audio\Brave\Brave_pcm.R.wav"...
-[truehd @ 00307360] Lossless check failed - expected 00, calculated 15.
[truehd @ 00307360] Lossless check failed - expected 00, calculated e7.
--[truehd @ 00307360] End of stream indicated.
[truehd @ 00307360] Lossless check failed - expected 00, calculated 91.
-[truehd @ 00307360] Lossless check failed - expected c2, calculated 6b.
-------------------------------------------------------------------[truehd @ 003
07360] Lossless check failed - expected 00, calculated 9a.
---[truehd @ 00307360] Lossless check failed - expected 00, calculated 9f.
-----[truehd @ 00307360] End of stream indicated.
[truehd @ 00307360] Lossless check failed - expected 51, calculated 2a.
[truehd @ 00307360] End of stream indicated.
a01 The original audio track has a constant bit depth of 20 bits.
eac3to processing took 4 minutes, 48 seconds.
Done.

C:\Program Files (x86)\eac3to>

[von Suppé]

I remember a same occasion from long time ago.
Can you to try to input the TrueHD stream and directly output to multichannel FLAC in eac3to? I know it sounds not logical because eac3to will have to decode the TrueHD stream first anyways and then convert, but I know it helped me once. Couldn't figure out why though.
Not sure if it'll help you in this case.

[Music Fan]

Hi,
what is the parameter to change the pitch (or not) of the sound when converting 25 to 24 fps (and vice versa), I guess one has the choice (because sometimes the pitch has to change -to adjust it when it was not done during Pal speed up-, sometimes it has not to).
I guess that -slowdown and -speedup change the pitch and -changeTo.. does not but I'm not sure, thanks.

[Overdrive80]

The conversions of eac3to does not fix pitch, you will need http://avisynth.nl/index.php/SSRC

[Music Fan]

The conversions of eac3to does not fix pitch, you will need http://avisynth.nl/index.php/SSRC
Thanks, this filter only works with avisynth I guess.
Does it always change the pitch ? I don't see option to avoid it.

In this case, what's the difference between -slowdown (or-speedup) and -changeTo in eac3to ?

[Reino]

Hi,
what is the parameter to change the pitch (or not) of the sound when converting 25 to 24 fps (and vice versa)I'm not too sure about eac3to, someone else can probably help you with that, but alternatively you can use AviSynth, FFMpeg, or SoX as explained in this post.

[sneaker_ger]

Does it always change the pitch ?
Yes, eac3to always does.

In this case, what's the difference between -slowdown (or-speedup) and -changeTo in eac3to ?
No difference. (-changeTo is just useful for when the auto-fps-guessing fails)

[Music Fan]

Ok.

Yes, eac3to always does.
I was talking about SSRC.

[Music Fan]

I'm not too sure about eac3to, someone else can probably help you with that, but alternatively you can use AviSynth, FFMpeg, or SoX as explained in this post.
Thanks, I will have a look on this.

[upyzl]

problem for compiling eac3to-ffmpeg...(I want to try latest ffmpeg to see any improvement, especially in TrueHD, as eac3to stagnates for a long time)

I'm followed by ./legal stuff/ffmpeg steps (slightly mod for ac3dec for match latest ffmpeg also, same config)
but when make install here: (tried TDM-GCC 4.7.1-2 / TDM-GCC 4.8.1-3)
common.mak:18: *** unterminated call to function `foreach': missing `)'. Stop.

also tried normal mingw (gcc 4.8.3)
another error
common.mak:152: *** missing separator. Stop.

but I don't find any strange in common.mak...

line 18-19:$(foreach VAR,$(BRIEF), \
$(eval override $(VAR) = @$$(call ECHO,$(VAR),$$(MSG)); $($(VAR))))
(I've tried change to one line, it is the same for TDM-GCC)

line 152:$(eval $(RULES))


full:#
# common bits used by all libraries
#

# first so "all" becomes default target
all: all-yes

ifndef SUBDIR

ifndef V
Q = @
ECHO = printf "$(1)\t%s\n" $(2)
BRIEF = CC CXX HOSTCC HOSTLD AS YASM AR LD STRIP CP WINDRES
SILENT = DEPCC DEPHOSTCC DEPAS DEPYASM RANLIB RM

MSG = $@
M = @$(call ECHO,$(TAG),$@);
$(foreach VAR,$(BRIEF), \
$(eval override $(VAR) = @$$(call ECHO,$(VAR),$$(MSG)); $($(VAR))))
$(foreach VAR,$(SILENT),$(eval override $(VAR) = @$($(VAR))))
$(eval INSTALL = @$(call ECHO,INSTALL,$$(^:$(SRC_DIR)/%=%)); $(INSTALL))
endif

ALLFFLIBS = avcodec avdevice avfilter avformat avresample avutil postproc swscale swresample

# NASM requires -I path terminated with /
IFLAGS := -I. -I$(SRC_PATH)/
CPPFLAGS := $(IFLAGS) $(CPPFLAGS)
CFLAGS += $(ECFLAGS)
CCFLAGS = $(CPPFLAGS) $(CFLAGS)
ASFLAGS := $(CPPFLAGS) $(ASFLAGS)
CXXFLAGS += $(CPPFLAGS) $(CFLAGS)
YASMFLAGS += $(IFLAGS:%=%/) -Pconfig.asm

HOSTCCFLAGS = $(IFLAGS) $(HOSTCPPFLAGS) $(HOSTCFLAGS)
LDFLAGS := $(ALLFFLIBS:%=$(LD_PATH)lib%) $(LDFLAGS)

define COMPILE
$(call $(1)DEP,$(1))
$($(1)) $($(1)FLAGS) $($(1)_DEPFLAGS) $($(1)_C) $($(1)_O) $<
endef

COMPILE_C = $(call COMPILE,CC)
COMPILE_CXX = $(call COMPILE,CXX)
COMPILE_S = $(call COMPILE,AS)
COMPILE_HOSTC = $(call COMPILE,HOSTCC)

%.o: %.c
$(COMPILE_C)

%.o: %.cpp
$(COMPILE_CXX)

%.o: %.m
$(COMPILE_C)

%.s: %.c
$(CC) $(CPPFLAGS) $(CFLAGS) -S -o $@ $<

%.o: %.S
$(COMPILE_S)

%_host.o: %.c
$(COMPILE_HOSTC)

%.o: %.rc
$(WINDRES) $(IFLAGS) --preprocessor "$(DEPWINDRES) -E -xc-header -DRC_INVOKED $(CC_DEPFLAGS)" -o $@ $<

%.i: %.c
$(CC) $(CCFLAGS) $(CC_E) $<

%.h.c:
$(Q)echo '#include "$*.h"' >$@

%.ver: %.v
$(Q)sed 's/$$MAJOR/$($(basename $(@F))_VERSION_MAJOR)/' $^ > $@

%.c %.h: TAG = GEN

# Dummy rule to stop make trying to rebuild removed or renamed headers
%.h:
@:

# Disable suffix rules. Most of the builtin rules are suffix rules,
# so this saves some time on slow systems.
.SUFFIXES:

# Do not delete intermediate files from chains of implicit rules
$(OBJS):
endif

include $(SRC_PATH)/arch.mak

OBJS += $(OBJS-yes)
SLIBOBJS += $(SLIBOBJS-yes)
FFLIBS := $($(NAME)_FFLIBS) $(FFLIBS-yes) $(FFLIBS)
TESTPROGS += $(TESTPROGS-yes)

LDLIBS = $(FFLIBS:%=%$(BUILDSUF))
FFEXTRALIBS := $(LDLIBS:%=$(LD_LIB)) $(EXTRALIBS)

OBJS := $(sort $(OBJS:%=$(SUBDIR)%))
SLIBOBJS := $(sort $(SLIBOBJS:%=$(SUBDIR)%))
TESTOBJS := $(TESTOBJS:%=$(SUBDIR)%) $(TESTPROGS:%=$(SUBDIR)%-test.o)
TESTPROGS := $(TESTPROGS:%=$(SUBDIR)%-test$(EXESUF))
HOSTOBJS := $(HOSTPROGS:%=$(SUBDIR)%.o)
HOSTPROGS := $(HOSTPROGS:%=$(SUBDIR)%$(HOSTEXESUF))
TOOLS += $(TOOLS-yes)
TOOLOBJS := $(TOOLS:%=tools/%.o)
TOOLS := $(TOOLS:%=tools/%$(EXESUF))
HEADERS += $(HEADERS-yes)

PATH_LIBNAME = $(foreach NAME,$(1),lib$(NAME)/$($(CONFIG_SHARED:yes=S)LIBNAME))
DEP_LIBS := $(foreach lib,$(FFLIBS),$(call PATH_LIBNAME,$(lib)))

SRC_DIR := $(SRC_PATH)/lib$(NAME)
ALLHEADERS := $(subst $(SRC_DIR)/,$(SUBDIR),$(wildcard $(SRC_DIR)/*.h $(SRC_DIR)/$(ARCH)/*.h))
SKIPHEADERS += $(ARCH_HEADERS:%=$(ARCH)/%) $(SKIPHEADERS-)
SKIPHEADERS := $(SKIPHEADERS:%=$(SUBDIR)%)
HOBJS = $(filter-out $(SKIPHEADERS:.h=.h.o),$(ALLHEADERS:.h=.h.o))
checkheaders: $(HOBJS)
.SECONDARY: $(HOBJS:.o=.c)

alltools: $(TOOLS)

$(HOSTOBJS): %.o: %.c
$(COMPILE_HOSTC)

$(HOSTPROGS): %$(HOSTEXESUF): %.o
$(HOSTLD) $(HOSTLDFLAGS) $(HOSTLD_O) $^ $(HOSTLIBS)

$(OBJS): | $(sort $(dir $(OBJS)))
$(HOBJS): | $(sort $(dir $(HOBJS)))
$(HOSTOBJS): | $(sort $(dir $(HOSTOBJS)))
$(SLIBOBJS): | $(sort $(dir $(SLIBOBJS)))
$(TESTOBJS): | $(sort $(dir $(TESTOBJS)))
$(TOOLOBJS): | tools

OBJDIRS := $(OBJDIRS) $(dir $(OBJS) $(HOBJS) $(HOSTOBJS) $(SLIBOBJS) $(TESTOBJS))

CLEANSUFFIXES = *.d *.o *~ *.h.c *.map *.ver *.ho *.gcno *.gcda
DISTCLEANSUFFIXES = *.pc
LIBSUFFIXES = *.a *.lib *.so *.so.* *.dylib *.dll *.def *.dll.a

define RULES
clean::
$(RM) $(OBJS) $(OBJS:.o=.d)
$(RM) $(HOSTPROGS)
$(RM) $(TOOLS)
endef

$(eval $(RULES))

-include $(wildcard $(OBJS:.o=.d) $(HOSTOBJS:.o=.d) $(TESTOBJS:.o=.d) $(HOBJS:.o=.d) $(SLIBOBJS:.o=.d))

could any one give me a guide...?

Edit: after
$git config --global core.autocrlf false
and git revert
use make 3.82 instead of 3.81
Now no common.mak error, but get compile error, I'll try later...

Edit2: using Tag n2.2.6 compile successful, but seems entry point avcodec_open changed from avcodec-54.dll to avcodec-55.dll(rename avcodec-54.dll when use), eac3to cannot call it...hope for official eac3to update (54/55 should be avcodec API version?)

[RRAH]

No matter the source/decoder or encoder, when you downmix 6.1 to 5.1 with eac3to need use:

-0,1,2,3,5,6,4 -down6

Hello,

Is this still required or is the problem solved?

Thanks

[tebasuna51]

@RRAH
Solved with eac3to v3.27

[Music Fan]

I converted 1 mpa and 1 ac3 file, both in 48-16 to wav, and I saw this message during conversion : "reducing depth from 64 to 24 bits".
Does it mean there is always a 64 bits step during process ?
Or is it a difficulty for eac3to to interpret the format as 16 bits with some files and thus consider them as 64 bits ?
When I add -down16, it is well converted in 16 bits.
Does is stay in 16 bits when -down16 is added or there is a 64 bits step anyway (16 => 64 => 16) ?

[RRAH]

@RRAH
Solved with eac3to v3.27

Thanks @Tebasuna :-)

[nevcairiel]

I converted 1 mpa and 1 ac3 file, both in 48-16 to wav, and I saw this message during conversion : "reducing depth from 64 to 24 bits".
Does it mean there is always a 64 bits step during process ?
Or is it a difficulty for eac3to to interpret the format as 16 bits with some files and thus consider them as 64 bits ?
When I add -down16, it is well converted in 16 bits.
Does is stay in 16 bits when -down16 is added or there is a 64 bits step anyway (16 => 64 => 16) ?

Lossy compressed audio like ac3 is decoded to floating point by the built-in ffmpeg decoder, it doesn't start out as 16 in the first place.

[tebasuna51]

I converted 1 mpa and 1 ac3 file, both in 48-16 to wav,...
Lossy compressed audio don't have bitdepth, only lossless compresion can have the precission to restore the original bitdepth.

Lossy decoders (AC3, standard DTS, MP3, MP2, AAC, ...) works internally decoding samples in frequency domain to float samples (32 or 64 bits like eac3to) in time domain (PCM).

Any subsequent conversion is always unnacurate with less precission than 16 bits, eac3to select by default convert to 24 bits int, but you can choice preserve the 64 bits float with -full, convert to 32 bit int with -down32 or convert to 16 bits int with -down16.

[Music Fan]

Thanks, that's amazing, I never heard of it.
But I guess that 16 bit waves compressed in ac3, aac, mpa ... stay in 16 bit in a certain way ? For players and analyzers (MediaInfo), it's supposed to be 16 bit.
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 ?

edit : I was wrong, players and analyzers do not show the quantification but only the frequency with lossy compressed files, except with some files (for a TS including ac3 @ 448 k, MediaInfo indicates 16 bits).
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.

[Boulder]

Yes, I can confirm than LFE decoded with Arcsoft 1.1.0.0 is 3 dB louder than the LFE channel decoded with Foobar2000 decoder or with the AviSynth NicAudio decoder.I tried to reproduce this earlier but couldn't. I decoded a normal DTS-HD MA 5.1ch file to WAV with both Arcsoft 1.1.0.0 and Sonic and the results were the same.

[nixo]

I think tebasuna51 and torturesauce were discussing lossy DTS, not DTS-HD.

--
Nikolaj

[tebasuna51]

...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]

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]

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]

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.

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]

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.

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]

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]

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]

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...:rolleyes:

[Music Fan]

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 ;
the precission is always less than 16 bits in lossy formats.
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 ?


The unique measure of quality of a lossy compressed file is the bitrate and the compressor efficiency.
And sample frequency, right ?

[tebasuna51]

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.

[Thunderbolt8]

whats the correct file format to choose when demuxing DVB subtitles? I tried .srt and .sup, but both gave me errors.

[Music Fan]

I'm not sure eac3to handle DVB-SUB (bitmap based format) but Subtitle Edit does (it needs the TS file).
If you are talking about teletext subtitles format, TSDoctor, CCExtractor and maybe VideoRedo and ProjectX can convert it in srt (they also need the TS file).

[Music Fan]

I say because the samples in frequency domain are better calculated with a source more precisse.
I had understood but it seems contradictory with the fact that the precision is less than 16 bits in lossy formats.

[Overdrive80]

I had understood but it seems contradictory with the fact that the precision is less than 16 bits in lossy formats.

If you original source is 24 bit depth, the encoder will can calculate better because precision is greater than 16 bit depth source.

This and you say is contradictory, but not tebasuna51 says.

[Music Fan]

What is contradictory in my message ? I just asked questions.:confused:

the samples in frequency domain have a precission equivalent to a bitdepth of 20 bits.
the precission is always less than 16 bits in lossy formats
Logical for you ?:scared:

[nevcairiel]

The concept of bit depth just doesn't really translate to the frequency domain transforms used by the lossy codecs. Trying to speak about it will always sound contradictory since it just doesn't fit.

[tebasuna51]

When a lossy encoder make the change between time domain to frequency domain not all components fit in the bitrate assigned and discard the less important (for low volume or high frequency), for that you can't recover the original precission.

For example the DTS-MA make the 'core' like lossy standard DTS with a CBR bitrate and all components than not fit are stored in a subframe VBR, now we can recover the original precission.

[foxyshadis]

Here's why input bit depth matters. Obviously this is very artificial to make a point, but the higher the bitdepth, the less noise gets sprayed into the rest of the spectrum, which allows the encoder to encode the sound more accurately in less bits.

(One thing I have to comment on, everyone is assuming that all codecs use float internally, but most don't. Quite a few use DCTs/MDCTs optimized specifically for the bit-depth they internally operate at, which is usually 16-bit or 24-bit, though a few implementations can optionally use float. By the same measure, the specs usually only specify output at a certain bit-depth with a certain internal bit-depth; decoders going beyond that can't be "compliant" even if they can be theoretically slightly higher quality. Personally, I feel that the need for optimized audio algorithms is past, when I can do 100x realtime transcoding, and an all-float chain is important, even if it's not perfectly to-spec.)

[Music Fan]

Thanks for this explanation.
You didn't write whats is the difference between these 2 images, I guess the source of the first is 24 bit and 16 for the second, right ?

[LigH]

It doesn't even matter much how many bits of resolution there is exactly in these waveforms. May it be only 8 bit on the right side. But what you see is the bad side effect of "quantization". If samples have too little resolution, the conversion to a frequency spectrum will have artefacts. Backwards the same problem: If the frequency spectrum parameters have too low precision, the reconstructed waveform will have artefacts. Lossy compression is mostly about reducing the precision of the frequency spectrum, though, so there is much effort to try to make the resulting artefacts unobvious, or at least not so annoying...