View Full Version : eac3to - audio conversion tool
mastrandrea
11th June 2012, 19:04
Thank you both!
mp3dom
15th June 2012, 13:13
I have a question that probably was already answered but I can't find a clear post (most of them refers to dts-hd 6.1 to 5.1 remapping channels). I have a 6.1 interleaved wave with the following mappings:
Left
Right
Center
LFE
Left Surround
Right Surround
Back-Center Surround
I want to downmix to 5.1 with eac3to. Is this channelmap already ok for what eac3to expect, or do I need to switch some channel (like put Back Center Surround between LFE and Left Surround?).
Thanks!
ramicio
15th June 2012, 13:47
If they are already in a WAV then they are likely in the correct order. WAV has a standardized channel order. Are the surrounds "back" or "side?"
mp3dom
15th June 2012, 14:07
The surrounds are all back channels. The interleaved wave was made from 7 mono files (I think using SoundForge or Nuendo)
ramicio
15th June 2012, 14:08
Well, if you put the files in the correct order to interleave the file, and it has the correct channel mask, then there will be zero problems.
Carpo
15th June 2012, 15:32
instead of reading 583 pages and trying to use the search here that never finds what i'm after, I will ask a question that has already been asked, but is there any chance of eac3to being updated to use LAV filters instead of/ as well as haali?
ramicio
15th June 2012, 15:36
Isn't Haali just a splitter? I see a file in the eac3to directory called avcodec.dll. Is this not libavcodec, which that LAV Filters thing is based off of?
Carpo
15th June 2012, 16:22
it would still need to be made aware of lav and what it can do
ramicio
15th June 2012, 16:23
What?
Carpo
15th June 2012, 16:26
you cant just drop a dll in the folder and expect it to know what LAV is and what lav can do, avcodec-lav-54.dll which is the lastest version that comes with LAV filters may have changed from the version that comes with eac3to and cause errors
ramicio
15th June 2012, 16:27
But who cares? It does all it needs to do. Just because libavcodec has been updated, that doesn't mean eac3to will ever support writing to those extra formats. I don't really get what you're after here.
Carpo
15th June 2012, 16:33
in order for it to see mkv's or in this case mux them it uses haali
For video muxing you need:
(1) Haali Matroska Muxer
I am asking that LAV Splitter be added there, so we can use that instead of having to install and use haali
ramicio
15th June 2012, 16:35
What's wrong with using Haali? It's much better than the crap in libavcodec.
Carpo
15th June 2012, 16:36
nothing is wrong with it, and libavocdec is far from crap, have you ever used LAV filters?
ramicio
15th June 2012, 16:40
There's no need for me to. It's the same thing as FFDShow. MPC-HC's internal MKV filter is not as good as Haali.
I also have zero hope in eac3to ever being updated.
sneaker_ger
15th June 2012, 18:46
Even LAV uses Haali's code.
Carpo
15th June 2012, 23:12
ffdshow uses it mplayer, lav - quite a few things do
v___v
16th June 2012, 21:01
Hihihi.
If what I'm about to ask seems redundant or as if I didn't look through the proper channels (internet/documentation) thoroughly enough, I apologize. I really did try to look for the answer beforehand.
I'm trying to decode the lossless portion of DTS-HD MA audio. But I'm not sure what I am doing is working.
This is the file (http://susepaste.org/view/raw/30197475) I am working with. This is the output (http://susepaste.org/view/raw/93951891) of my eac3to setup with the -test parameter.
Alright, so when I try eac3to file.dts file.flac or eac3to file.dts file.wav, I get the following output for instance of FLAC (http://susepaste.org/view/raw/52117386) or wav (http://susepaste.org/view/raw/21417270) (also put mediainfo output for the output file there).
It says it's "decoding with ArcSoft DTS Decoder" but the following line mentions the core's information...
So here's what I'm wondering:
- Is it really decoding the lossless -> flac/wav? This seems like it's decoding the lossy core then transcoding that to flac/wav. So lossy -> lossless ?
- Is it possible that I am doing it wrong? (incorrect parameters, wrong thing to use, etc)
- Is it possible that this has something to do with the versions of ArcSoft/eac3to I have?
Any clarification/assistance would be helpful.
tebasuna51
16th June 2012, 23:38
...
- Is it really decoding the lossless -> flac/wav?
Yes
This seems like it's decoding the lossy core then transcoding that to flac/wav. So lossy -> lossless ?
Nope, the line:
"(core: DTS, 5.1 channels, 16 bits, 1509kbps, 48kHz)"
is only a info. ArcSoft decode the DTS-MA lossless.
All is OK.
Leinad4Mind
29th June 2012, 00:26
I've an DTS-HD Master Audio 7.1 and I want to encode to AAC-LC 7.1.
If I extract the core:
eac3to input.dtshd output.dts -core
I get an 5.1 .dts. After that I can encode to aac... but I will have an AAC-LC 5.1. I want 7.1 :(
If I try to extract on pcm:
eac3to input.dtshd output.wavs
The program begin to extract 8 tracks... but it goes wrong... after some minutos one error comes up: "The ArcSoft DTS Decoder reported an error while decoding. Aborted at file position 11567589376"
I've tried to .flac too, but withou sucess, same error.
eac3to v3.24
command line: eac3to "INPUT_ING.dtshd" "OUTPUT_ING.flac"
------------------------------------------------------------------------------
DTS Master Audio, 7.1 channels, 16 bits, 48kHz
(core: DTS, 5.1 channels, 16 bits, 1509kbps, 48kHz)
Decoding with ArcSoft DTS Decoder...
Encoding FLAC with libFlac...
Creating file "OUTPUT_ING.flac"...
The ArcSoft DTS Decoder reported an error while decoding. <ERROR>
Aborted at file position 1167589376. <ERROR>
What I'm doing wrong?
Cheers!
Adub
29th June 2012, 00:32
(core: DTS, 5.1 channels, 16 bits, 1509kbps, 48kHz)
The core IS 5.1, that's why it's called the core. You won't get 7.1 by extracting the core.
Asmodian
29th June 2012, 00:34
That looks like a corrupted DTS-HD file to me, given the error is in ArcSoft not eac3to I don't think a setting will help.
Maybe there was an error while ripping (I assume this file was from a bluray?).
Leinad4Mind
29th June 2012, 00:39
I know if I extract the core I get an 5.1 xD I was just explaining.
And exactly, Asmodian, its from an bluray.
eac3to v3.24
command line: eac3to "Adormecida_ING.dtshd" "Adormecida_ING_dts.wavs" -16 -48000 -8 -little
------------------------------------------------------------------------------
DTS Master Audio, 7.1 channels, 16 bits, 48kHz
(core: DTS, 5.1 channels, 16 bits, 1509kbps, 48kHz)
Decoding with ArcSoft DTS Decoder...
Writing WAVs...
Creating file "Adormecida_ING_dts.L.wav"...
Creating file "Adormecida_ING_dts.C.wav"...
Creating file "Adormecida_ING_dts.BL.wav"...
Creating file "Adormecida_ING_dts.SL.wav"...
Creating file "Adormecida_ING_dts.R.wav"...
Creating file "Adormecida_ING_dts.LFE.wav"...
Creating file "Adormecida_ING_dts.BR.wav"...
Creating file "Adormecida_ING_dts.SR.wav"...
The ArcSoft DTS Decoder reported an error while decoding. <ERROR>
Aborted at file position 1167589376. <ERROR>
So... the dtshd must be corrupt. I will extract again from the bluray. Do you recomend TSMuxer or HdBrStreamExtractor to extract the audio?
Cheers!
sl1pkn07
29th June 2012, 01:25
try eac3to directly
go to root of BD rip folder (example: c:\Adormecida) and tip "eac3to.exe 1) adormecida.aac". this extract directly from m2ts if BDMV is rip/unlocked by anydvdHD/dvdfabHD/makemkv backup option
Snowknight26
29th June 2012, 17:17
Does it really matter? It's 1 millisecond.
Asmodian
29th June 2012, 18:22
It isn't even a matter of noticing the 1 ms. You would still seak to the same frame given that a single frame is displayed for >16ms even with 60 fps material so nothing changes.
Maybe eac3to is setting chapter points to the nearest frame start time while the other programs are less aware of (or do not care about) the exact frame start/stop times. Or maybe they are rounding all the times to the nearest 10ms? I often see only two digits for ms time stamps in editing programs (HH:MM:SS.ss not HH:MM:SS.sss).
It would be nice to know why of course but I would trust eac3to over the others if I had to pick one.
frank
2nd July 2012, 07:43
AFAIK this 1 ms difference is a rounding error. Very annoying!
mkv is very picky.
When you jump to a chapter it will never get the key frame on that chapter point if the time is 1 ms shorter!
mkv jumps to the next frame starting WITHIN the time -40 ms...-41 ms (1 / fps). That is the key frame or the last decoded frame before the time stamp.
As workaround I add 2 ms to the chapters on every rip.
Leinad4Mind
3rd July 2012, 14:02
try eac3to directly
go to root of BD rip folder (example: c:\Adormecida) and tip "eac3to.exe 1) adormecida.aac". this extract directly from m2ts if BDMV is rip/unlocked by anydvdHD/dvdfabHD/makemkv backup option
I've tried that, but I got just 1h of the movie :(
eac3to v3.24
command line: eac3to.exe 1) adormecida.aac
------------------------------------------------------------------------------
M2TS, 2 video tracks, 7 audio tracks, 21 subtitle tracks, 1:15:10, 24p /1.001
1: Chapters, 30 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: h264/AVC, 480p24 /1.001 (20:11)
4: DTS Master Audio, English, 7.1 channels, 16 bits, 48kHz
(core: DTS, 5.1 channels, 16 bits, 1509kbps, 48kHz)
5: AC3 Surround, English, 2.0 channels, 192kbps, 48kHz
6: AC3, English, 2.0 channels, 192kbps, 48kHz
7: AC3, Portuguese, 5.1 channels, 640kbps, 48kHz
8: AC3, Polish, 5.1 channels, 640kbps, 48kHz
9: AC3, Russian, 5.1 channels, 640kbps, 48kHz
10: AC3, Arabic, 5.1 channels, 640kbps, 48kHz
11: Subtitle (PGS), English
12: Subtitle (PGS), English
13: Subtitle (PGS), English
14: Subtitle (PGS), English
15: Subtitle (PGS), English
16: Subtitle (PGS), Portuguese
17: Subtitle (PGS), Polish
18: Subtitle (PGS), Russian
19: Subtitle (PGS), Arabic
20: Subtitle (PGS), Portuguese
21: Subtitle (PGS), Polish
22: Subtitle (PGS), Russian
23: Subtitle (PGS), Arabic
24: Subtitle (PGS), Portuguese
25: Subtitle (PGS), Polish
26: Subtitle (PGS), Russian
27: Subtitle (PGS), Arabic
28: Subtitle (PGS), Portuguese
29: Subtitle (PGS), Polish
30: Subtitle (PGS), Russian
31: Subtitle (PGS), Arabic
Track 4 is used for destination file "adormecida.aac".
[a04] Extracting audio track number 4...
[a04] Decoding with ArcSoft DTS Decoder...
[a04] Encoding AAC <0.50> with NeroAacEnc...
[a04] [1:00:41] The source file seems to be damaged (sync byte missing). <WARNING>
[a04] [1:00:41] The source file seems to be damaged (sync byte missing). <WARNING>
[a04] [1:00:41] The source file seems to be damaged (discontinuity). <WARNING>
[a04] The ArcSoft DTS Decoder reported an error while decoding. <ERROR>
Aborted at file position 15091105792. <ERROR>
This never happend to me before... Maybe the Bluray has some protections?! I will try to use DVD PassKey, and see if I pass to the hard drive without corrupting the audio.
Sparktank
3rd July 2012, 21:24
I just came across something interesting.
I bought Aliens on Blu-Ray and ripped it to MKV using MakeMKV (free while in Beta) and ran it through eac3to.
I found the audio for the director's cut had a range of bit-depth.
Here's the log:
eac3to v3.24
command line: "C:\Apps\eac3to\eac3to.exe" "G:\1080p\Aliens\Aliens.mkv" 1: Aliens.h264 2: Aliens.ac3 -448 3:Aliens_2.ac3 4: Aliens_3.ac3
------------------------------------------------------------------------------
MKV, 1 video track, 3 audio tracks, 2:34:27, 24p /1.001
1: h264/AVC, 1080p24 /1.001 (16:9)
2: DTS Master Audio, 5.1 channels, 24 bits, 48kHz
(core: DTS, 5.1 channels, 24 bits, 1509kbps, 48kHz)
"Lossless"
3: AC3 Surround, 2.0 channels, 224kbps, 48kHz, dialnorm: -27dB
"2/0"
4: AC3, 2.0 channels, 224kbps, 48kHz, dialnorm: -27dB
"2/0"
[v01] Extracting video track number 1...
[a02] Extracting audio track number 2...
[a03] Extracting audio track number 3...
[a04] Extracting audio track number 4...
[a03] Removing AC3 dialog normalization...
[a04] Removing AC3 dialog normalization...
[a02] Decoding with ArcSoft DTS Decoder...
[a02] Encoding AC3 <448kbps> with libAften...
[v01] Creating file "Aliens.h264"...
[a02] Creating file "Aliens.ac3"...
[a03] Creating file "Aliens_2.ac3"...
[a04] Creating file "Aliens_3.ac3"...
[a02] Original audio track: max 24 bits, average 19 bits, most common 16 bits.
Video track 1 contains 222185 frames.
eac3to processing took 1 hour, 14 minutes.
Done.
I haven't tried from the disc directly. Going to try that later and see if it's relatively the same.
Need to update DVDfab Passkey first.
Also haven't tried the theatrical edition either.
But from all the Blu-Rays I have, I've not seen that before.
Is that some kind of error or is there such a thing as VBR for Bit-Depth?
I know there's usually constant of 20 inside a 24 container.
so confused right now.
*sips coffee*
sl1pkn07
4th July 2012, 00:48
if try "eac3to 1) -check" ?
-check checks if the source EVO/(M2)TS file is clean.
setarip_old
4th July 2012, 01:56
@Sparktank
Hi!
What, if any, problems does this apparent anomaly cause for you?
Sparktank
4th July 2012, 05:12
@Sparktank
Hi!
What, if any, problems does this apparent anomaly cause for you?
Well, no problems at all.
Just curious as to what this is all about; never have seen this information before in eac3to. :p
Audio plays back fine.
ramicio
5th July 2012, 15:08
It just shows you the true bit depth of the audio. Some of that audio is 24 bits, and some is 16 bits. The total content of each average together to be 19 bits. Since it's only 19 bits average, most of it is 16 bits. It doesn't matter, anyway, since you converted to ac3, which doesn't have a bit depth, but it's decoded to 16-bit accuracy. Sometimes I see a most common 20 bits. I don't understand why there is no 20 bit, it has to be put into a 24 bit container.
xkodi
5th July 2012, 22:42
hi All, i missed that ETSI actually released DTS-HD specifications:
http://www.etsi.org/deliver/etsi_ts/102100_102199/102114/01.03.01_60/ts_102114v010301p.pdf
and i'm not sure if that was covered here.
so, i remember back in the old days when all DTS-HD headers were just partially guessed by 'madshi', i.e. mainly the channel configuration information from the header and eac3to was the only application that was actually able to display with '-logdts' undocumented switch and use that information from the DTS-HD headers.
so, that same limitation, i.e. lack of knowledge about DTS-HD headers was the reason that eac3to wasn't and it still is not able to decode all DTS-HD stream properly - for example "7.1 (strange setup)", because that same issue for DTS was solved by idea i suggested several times:
http://forum.doom9.org/showthread.php?p=1180214#post1180214
and at the end 'madshi' implemented, i.e. patching the DTS headers to channel configuration that is properly decoded and then remap the channels, as mentioned here:
http://forum.doom9.org/showthread.php?p=1180224#post1180224
so, the same idea was hard to achieve if not even impossible with DTS-HD due to lack of knowledge about the DTS-HD headers, but it seems with the ETSI PDF document with the DTS-HD specification that is no longer true.
so, eac3to is slowly getting outdated and it seems new open source initiative of new alternative to eac3to is a good idea - i'm sure i'm not the only one that is interested "7.1 (strange setup)" and other not properly decoded DTS-HD tracks by eac3to to be fixed. however, maybe netirely new tool is too much work and as a first step and proof of concept small tool that patches the DTS-HD headers, then use eac3to to decode and then another small tool to remap the channels is more feasible option, i.e. set of small tools to patch what eac3to is lacking as functionality. anyone interested?
73ChargerFan
7th July 2012, 19:51
I think you're underestimating the work involved duplicating eac3to. Just about every free tool out there uses it as a component.
BugiBugBug
10th July 2012, 08:20
I'm consistently experiencing sync problems when recoding the DTS track in my previously ripped MKVs to multichannel AAC.
The method I use is to load a given 720p MKV containing a DTS track, using the HdBrStreamExtractor with ArcSoft and NeroAAC, demuxing the H264 to a *.264 file, transcoding the DTS directly to AAC using -quality=0.45, and demuxing any contained SRT.
This goes without any problems (although it does almost every single time warn about some non-standard video bitstream stuff):
MKV, 1 video track, 1 audio track, 1:45:55, 24p /1.001
1: h264/AVC, English, 1280x536 23.975p
2: DTS, 5.1 channels, 24 bits, 1509kbps, 48kHz
[v01] The video bitstream is encoded in a non-standard framerate. <WARNING>
[v01] The video bitstream framerate field doesn't match the container framerate. <WARNING>
[v01] Extracting video track number 1...
[a02] Extracting audio track number 2...
[a02] Decoding with ArcSoft DTS Decoder...
[a02] Encoding AAC <0.45> with NeroAacEnc...
[v01] Creating file "D:\1_1_video.h264"...
Video track 1 contains 152373 frames.
eac3to processing took 20 minutes, 35 seconds.
Done.
When remuxing the stuff back to MKV with MKVToolnix, the audio is consistently a fraction of a second before the video; I've tested this with three video's now. The sync problem worsens over the course of the video; at the end the sync is worse than in the beginning.
Clearly my first idea is that this could have something to do with audio being sped up because of a 23,976 to 24 fps 'conversion' in the transcoding process. But I did not tell eac3to to do that. Maybe I'm missing something?
I've also noted that the resulting MKVs all have a 9ms delay applied to the audio; I do not understand where this comes from (it isn't present in mkvtoolnix stream settings), since no stream has this value incorporated, at least so MediaInfo tells me.
Does anyone have an idea what causes this?
Edit: I've tested setting mkv to 24p for muxing, but that doesn't work in the slightest bit; audio and video are now completely out of sync. This is driving me nuts - I had to free up disc space and deleted the source files, so now I'm stuck with 80GB of single streams that produce out-of-sync movies. *insert random power-curse*
kypec
10th July 2012, 08:46
When remuxing the stuff back to MKV with MKVToolnix, the audio is consistently a fraction of a second before the video; I've tested this with three video's now. The sync problem worsens over the course of the video; at the end the sync is worse than in the beginning.
Clearly my first idea is that this could have something to do with audio being sped up because of a 23,976 to 24 fps 'conversion' in the transcoding process. But I did not tell eac3to to do that. Maybe I'm missing something?
I've also noted that the resulting MKVs all have a 9ms delay applied to the audio; I do not understand where this comes from (it isn't present in mkvtoolnix stream settings), since no stream has this value incorporated, at least so MediaInfo tells me.
Does anyone have an idea what causes this?
Edit: I've tested setting mkv to 24p for muxing, but that doesn't work in the slightest bit; audio and video are now completely out of sync. This is driving me nuts - I had to free up disc space and deleted the source files, so now I'm stuck with 80GB of single streams that produce out-of-sync movies. *insert random power-curse*
I use eac3to only for audio re-encoding tasks, DTS->AAC like you do. Then I just use MKVToolnix to remux original MKV with M4A audio and I've never experienced any sync problems. That 9ms delay is probably a default AAC decoder delay which is inherently present in every AAC audio file, don't worry about it, mkvmerge just does its job reliably.
BugiBugBug
10th July 2012, 08:54
I use eac3to only for audio re-encoding tasks, DTS->AAC like you do. Then I just use MKVToolnix to remux original MKV with M4A audio and I've never experienced any sync problems. That 9ms delay is probably a default AAC decoder delay which is inherently present in every AAC audio file, don't worry about it, mkvmerge just does its job reliably.
Then this is -very- weird, because every file I remux is out of sync. One worse than the other (two were completely unwatchable).
I did have problems with my hard drives - it seemed the AHCI modus used on my AMD SB700 rig caused some writing/reading errors, maybe some bits have been 'shifted around' without me knowing. It never told me though, untill I started getting errors of programs being corrupt and such. Now I reinstalled my rig in RAID mode (single discs), which allows the use of RAIDXpert, which monitors stuff like that. Who needs S.M.A.R.T. if it doesn't work...
Luckily I know now I did not do anything wrong out of stupidity...
sneaker_ger
10th July 2012, 14:21
Mkvmerge automatically reads and applies the audio delay if present in apple style in the mp4 container. This is the case for files created by NeroAacEnc (used by eac3to). That explains the 9ms delay - not the progressive desync, though. The video is probably not strictly constant 24/1.001 fps.
BugiBugBug
10th July 2012, 15:26
Yes, I've been able to solve the problem for some of the movies by manually setting the frame duration to 24/1001 - this somehow proved to work best.
The one that proved progressively out of sync I removed already, so no way to test that. My guess is it would have improved as well.
The very badly out of sync ones were probably damaged; it was quite blocky here and there, artifacts showed up indicating a broken stream.
I've now reverted to only demuxing/transcoding the audio track, and using the original MKV stream to remux using the new audio (and leaving out the DTS). This has been showing the best results, consistently.
So I guess it's best to change as little as possible, and only mux/remux what you need to mux/remux. It also saves me a lot of time, since demuxing triple number amounts of gigabytes is not something you do very lightly.
PS. On a side note; WHY for gods sake does everyone keep using the horribly inefficient DTS? Please just use AAC already! Who needs 1500kbit/s for a simple audio track?! It's nuts!
ramicio
10th July 2012, 15:27
The video shows as 23.975 FPS. What are you setting it to for muxing?
Eac3to is fine for tasks other than just audio encoding. If you're getting corrupt data, it's likely a hardware issue, not eac3to.
BugiBugBug
10th July 2012, 15:50
The video shows as 23.975 FPS. What are you setting it to for muxing?
Eac3to is fine for tasks other than just audio encoding. If you're getting corrupt data, it's likely a hardware issue, not eac3to.
Good god, I did not even notice that five, I'm so used to seeing a particular number that I actually start seeing it when it isn't there...
Obviously the framerate that should have been used is different from the one of the stream; the log tells 24/1001, and the stream is 23.975. I'm guessing this very minor fraction caused the problems, and why setting it manually to 24/1001 solved these problems: an encode will in theory not be anything but one of the official frame durations. 23,975 is not the right number, and must be incorrect. 0,001 frame/s less does sum up to a larger delay in the end than in the beginning, because the video runs slower than the audio. This is really the culprit.
So the moral of the story is - keep track of your eac3to log files, and use another number if problems arise. And look at the numbers -closely- :)
marcusj0015
12th July 2012, 17:31
Hey Madshi, I have a question about Eac3to. Can I add flac specific options to the command line for Eac3to? Because Flac doesn't support writing files over 2GB, but eac3to can because it doesn't use Flac's built in IO stuff, and basically, I want to compress the flac file as heavily as possible. I'm only encoding once, might as well compress it as much as possible.
The commands from Flac I want to use are " -8 -e -p" -8 means best compression as I'm sure you know, but you may not know about the other ones. -e is "Exhaustive model search (expensive!). Normally the encoder estimates the best model to use and encodes once based on the estimate. With an exhaustive model search, the encoder will generate subframes for every order and use the smallest."
and -p is "Do exhaustive LP coefficient quantization optimization."
Basically, it'll slightly improve the file size, and over two hour file, I think it'd be worth it. anyway, how can I do this, and if I can't, can you add it?
Descriptions from Flacs documentation.
ramicio
12th July 2012, 20:55
-8 already implies the -e flag, and -p is not guaranteed to actually decrease file size.
Asmodian
13th July 2012, 01:36
Based on this post (http://forum.doom9.org/showthread.php?p=1222771&highlight=flac+compression+level#post1222771) from Madshi I think eac3to defaults to using compression level 8 for Flac.
marcusj0015
15th July 2012, 14:51
Thanks guys, I appreciate it. :)
rapscallion
15th July 2012, 17:24
Remember that theres a bigger Problem with the NeroAudio Decoder in eac3to! The DRC isnt removed properly so the Decoder is not recommended
I wouldnt use NERO AC3/EAC3 Decoder
http://forum.doom9.org/showthread.php?p=1404212#post1404212
Looks like DRC isnt disabled properly
Better use libav..works without Problems. And i dont think you hear big a Quality Difference generally between Nero and libavcodec on AC3/EAC3
AC hasn't been around for some time now.
Does anyone know if the above applies to both DD and True-HD ?
`Orum
21st July 2012, 16:42
Had an interesting problem today when trying to go from AC3 -> FLAC with a channel remap (in preparation for oggenc2 encoding). Here's the log:
AC3, 2.0 channels, 1:35:39, 224kbps, 48kHz
The Nero decoder doesn't seem to work, will use libav instead.
Decoding with libav/ffmpeg...
Remapping channels...
Reducing depth from 64 to 24 bits...
Encoding FLAC with libFlac...
Creating file "audio_bonus-oggorder.flac"...
Clipping detected, a 2nd pass will be necessary.
Starting 2nd pass...
Decoding with libav/ffmpeg...
Remapping channels...
Reducing depth from 64 to 24 bits...
Encoding FLAC with libFlac...
Applying -0.22dB gain...
The libav decoder crashed.
Creating file "audio_bonus-oggorder.flac"...
Aborted at file position 262144.
It handles the first pass without issue, and then, almost immediately upon attempting the second pass, it crashes? Strange...
Any idea how to work around it? Only thing I can think of is to possibly drop in a new libav decoder, but not sure what is compatible.
tebasuna51
22nd July 2012, 00:54
I never see that.
Try with only one pass.
Ignoring the "Clipping detected..." with:
eac3to input.ac3 stdout.wav -no2ndpass | OggEnc2 -q X -o output.ogg -
Or applying manually the needed -0.22dB gain...
eac3to input.ac3 stdout.wav -0.22dB | OggEnc2 -q X -o output.ogg -
`Orum
22nd July 2012, 19:14
Or applying manually the needed -0.22dB gain...
eac3to input.ac3 stdout.wav -0.22dB | OggEnc2 -q X -o output.ogg -
I tried this but it throws an error: Command line parameter "0.22dB" is unknown. I think it expects whole numbers for this?
It does work with -no2ndpass, but then it has some, albeit minor, clipping.
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.