AC3 5.1 Sound Issues

[Irtehpasty]

I've now tried various sources with DTS (DTS-HD) sound and it seems the conversion of either to a 6-channel discrete AC3 track (for .mp4 files) creates gaps and the audio skips. Other audio options work correctly, and the source files are directly from disc, which leads me to believe it's actually a problem with the conversion process through ffmpeg. But, I figured I'd post this here anyway to start.

I'm using the WinGUI (svn 4061) with the high profile preset on Windows 7.

[randomreuben]

You're probably a gentleman and a scholar and your friends have always said so, but no one trusts anything people say here other than the blessed log. Please provide the blessed log.

[JohnAStebbins]

I've now tried various sources with DTS (DTS-HD) sound and it seems the conversion of either to a 6-channel discrete AC3 track (for .mp4 files) creates gaps and the audio skips. Other audio options work correctly, and the source files are directly from disc, which leads me to believe it's actually a problem with the conversion process through ffmpeg. But, I figured I'd post this here anyway to start.

I'm using the WinGUI (svn 4061) with the high profile preset on Windows 7.

You're probably a gentleman and a scholar and your friends have always said so, but no one trusts anything people say here other than the blessed log. Please provide the blessed log.

Actually, there is a known problem with dts-hd audio. ffmpeg creates bogus jittery timestamps for dts-hd audio which makes it hard to sync to. There are a couple alternative patches that seem fix the problem. But none have made it into svn yet.

[Irtehpasty]

You're probably a gentleman and a scholar and your friends have always said so, but no one trusts anything people say here other than the blessed log. Please provide the blessed log.

I didn't think a log would be too helpful since it happens with every audio transcode from DTS to AC3. But yes I do realize I forgot that standard bug forum rule.

Actually, there is a known problem with dts-hd audio. ffmpeg creates bogus jittery timestamps for dts-hd audio which makes it hard to sync to. There are a couple alternative patches that seem fix the problem. But none have made it into svn yet.

Ok, well I'll keep watching the svn for when a fix is added (hopefully soon!) and put the movies with DTS on the back burner. Thanks for the quick reply!

EDIT: Having a thought here, with the libav fork of ffmpeg would it be more plausible to get a fix pushed for the DTS to AC3 timestamp issues?

[JohnAStebbins]

Having a thought here, with the libav fork of ffmpeg would it be more plausible to get a fix pushed for the DTS to AC3 timestamp issues?

I've pointed out the problem and described in detail the cause of the problem on the libav-devel mailing list. It didn't seem to get much response. I think it will get fixed when they get around to fully implementing dts-hd decode. Right now they are only decoding the dts core. That causes them to estimate the bitrate incorrectly for dts streams that have the hd extension (and thus a different bitrate than the core indicates). Then they do something that I think is just pant-on-head retarded. Any time a frame doesn't have a timestamp, they try to guess what the timestamp is based on the bitrate of the stream and the number of bytes in the compressed frame. Since the bitrate is wrong, the timestamp guess is wrong and the timestamps progressively slip till the next real timestamp in the stream is encountered. Then it jerks back into place, which usually makes it appear that time when backwards.

So, IMO the correct solution to this (and many other timestamp related ffmpeg problems) is to stop trying to estimate timestamps with insufficient information. Leave it to the calling application to fix timestamps when more information is available after decoding the frame. But I think that's likely to be an unpopular proposition.

[Deleted User 11865]

Then they do something that I think is just pant-on-head retarded. Any time a frame doesn't have a timestamp, they try to guess what the timestamp is based on the bitrate of the stream and the number of bytes in the compressed frame.

It's even more retarded when the track uses variable bitrate.

[Irtehpasty]

Well then no wonder the audio track is wrong. Their process really doesn't seem to make much sense, hopefully that gets sorted out soon. Maybe they'll take your suggestions eventually.

For now I'll work around it by playing around with MKVtoolnix and Aften. Thanks again for all your time!

[nightstrm]

Just want to make sure I understand the current state of things... Should I use The DTS-HD track or the DTS track (I assume this is the core) when converting bluray audio to AC3 (@640kbps)? Based on what I've read in this thread, Im thinking the DTS core is "safer".

[TedJ]

I'd agree... there's no benefit to using the DTS-HD track as ffmpeg will only use the standard DTS core.