eac3to - audio conversion tool - Page 585

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

Quote:

Originally Posted by setarip_old

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

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/...14v010301p.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.ph...14#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.ph...24#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):

Code:

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

Quote:

Originally Posted by BugiBugBug

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

Quote:

Originally Posted by kypec

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

Quote:

Originally Posted by ramicio

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

Quote:

Originally Posted by ACrowley

Remember that theres a bigger Problem with the NeroAudio Decoder in eac3to! The DRC isnt removed properly so the Decoder is not recommended

Quote:

Originally Posted by ACrowley

I wouldnt use NERO AC3/EAC3 Decoder
http://forum.doom9.org/showthread.ph...12#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:

Code:

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

Quote:

Originally Posted by tebasuna51

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.

5th July 2012, 22:42	#11684 \| Link
xkodi Registered User Join Date: Aug 2002 Posts: 221	hi All, i missed that ETSI actually released DTS-HD specifications: http://www.etsi.org/deliver/etsi_ts/...14v010301p.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.ph...14#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.ph...24#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? Last edited by xkodi; 5th July 2012 at 22:47.

10th July 2012, 08:20	#11686 \| Link
BugiBugBug Registered User Join Date: Dec 2006 Posts: 10	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): Code: 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* Last edited by BugiBugBug; 10th July 2012 at 08:37.

10th July 2012, 14:21	#11689 \| Link
sneaker_ger Registered User Join Date: Dec 2002 Posts: 5,565	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. Last edited by sneaker_ger; 10th July 2012 at 14:26.

22nd July 2012, 00:54	#11699 \| Link
tebasuna51 Moderator Join Date: Feb 2005 Location: Spain Posts: 6,915	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 - __________________ BeHappy, AviSynth audio transcoder.

4th July 2012, 01:56	#11681 \| Link
setarip_old Registered User Join Date: Aug 2005 Posts: 16,267	@Sparktank Hi! What, if any, problems does this apparent anomaly cause for you?

5th July 2012, 15:08	#11683 \| Link
ramicio Banned Join Date: Mar 2004 Location: PA, US Posts: 683	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.

7th July 2012, 19:51	#11685 \| Link
73ChargerFan Registered User Join Date: Dec 2006 Posts: 523	I think you're underestimating the work involved duplicating eac3to. Just about every free tool out there uses it as a component.

10th July 2012, 15:26	#11690 \| Link
BugiBugBug Registered User Join Date: Dec 2006 Posts: 10	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!

10th July 2012, 15:27	#11691 \| Link
ramicio Banned Join Date: Mar 2004 Location: PA, US Posts: 683	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.

12th July 2012, 17:31	#11693 \| Link
marcusj0015 Registered User Join Date: Mar 2012 Posts: 52	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.

12th July 2012, 20:55	#11694 \| Link
ramicio Banned Join Date: Mar 2004 Location: PA, US Posts: 683	-8 already implies the -e flag, and -p is not guaranteed to actually decrease file size.

13th July 2012, 01:36	#11695 \| Link
Asmodian Registered User Join Date: Feb 2002 Location: San Jose, California Posts: 4,407	Based on this post from Madshi I think eac3to defaults to using compression level 8 for Flac.

15th July 2012, 14:51	#11696 \| Link
marcusj0015 Registered User Join Date: Mar 2012 Posts: 52	Thanks guys, I appreciate it.