eac3to - audio conversion tool

[Boulder]

Originally Posted by tebasuna51

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]

Originally Posted by Overdrive80

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]

Originally Posted by 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'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]

Originally Posted by Music Fan

Does it always change the pitch ?

Yes, eac3to always does.

Originally Posted by Music Fan

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.

Originally Posted by sneaker_ger

Yes, eac3to always does.

I was talking about SSRC.

[Music Fan]

Originally Posted by CoRoNe

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]

Originally Posted by tebasuna51

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]

Originally Posted by tebasuna51

@RRAH
Solved with eac3to v3.27

Thanks @Tebasuna :-)

[nevcairiel]

Originally Posted by 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) ?

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]

Originally Posted by Music Fan

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]

Originally Posted by tebasuna51

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