Using ffmpeg instead of dcadec

[gamontecarlo]

Hi,
for me, dcadec fails on large files. It floods the terminal with "skip", and the ac3 file increases by 1MB in size every five minutes or so.

However, ffmpeg works as expected. Could you add a switch that uses ffmpeg instead of dcadec? The syntax would be:

ffmpeg -i FILE.dts -acodec ac3 -ac 6 -ab 640k FILE.ac3

Kind regards

[gamontecarlo]

http://pastebin.ca/2090283

There's obviously a patch for that :)

[gamontecarlo]

It serves another purpose, too:
dcadec+aften:

$ time dcadec -o wavall "some.dts" | aften - "some.ac3"

Aften: A/52 audio encoder
Version 0.0.8
(c) 2006-2007 Justin Ruggles, Prakash Punnoor, et al.

libdca-0.0.5 - by Gildas Bazin <gbazin@videolan.org>
  based on the a52dec code from Michel Lespinasse <walken@zoy.org> and Aaron Holtzman
Stream with high frequencies VQ coding
input format: WAVE Floating-point 32-bit little-endian 48000 Hz 5.1-channel
output format: 48000 Hz 3/2 + LFE

SIMD usage: MMX SSE SSE2 SSE3
Threads: 2

progress:   0% | q: 301.0 | bw: 33.9 | bitrate: 448.0 kbps 1593 frames in 1.00 s
(...)
701694 frames decoded in 395.73 seconds (1773.16 fps)
progress:   0% | q: 270.0 | bw: 34.0 | bitrate: 448.0 kbps 


real    6m35.948s
user    7m4.107s
sys 0m35.271s

ffmpeg:

$ time ffmpeg -i "some.dts" -acodec ac3 -ac 6 -ab 448k "some.ac3"
ffmpeg version 0.8.2, Copyright (c) 2000-2011 the FFmpeg developers
  built on Aug 15 2011 17:32:58 with gcc 4.2.1 (Apple Inc. build 5666) (dot 3)
  configuration: --prefix=/Volumes/Ramdisk/sw --enable-gpl --enable-pthreads --enable-version3 --enable-libspeex --enable-libvpx --disable-decoder=libvpx --enable-libmp3lame --enable-libtheora --enable-libvorbis --enable-libx264 --enable-avfilter --enable-libopencore_amrwb --enable-libopencore_amrnb --enable-filters --arch=x86_64 --enable-runtime-cpudetect
  libavutil    51.  9. 1 / 51.  9. 1
  libavcodec   53.  7. 0 / 53.  7. 0
  libavformat  53.  4. 0 / 53.  4. 0
  libavdevice  53.  1. 1 / 53.  1. 1
  libavfilter   2. 23. 0 /  2. 23. 0
  libswscale    2.  0. 0 /  2.  0. 0
  libpostproc  51.  2. 0 / 51.  2. 0
    [dts @ 0x101807c00] max_analyze_duration 5000000 reached at 5008378
    [dts @ 0x101807c00] Estimating duration from bitrate, this may be inaccurate
    Input #0, dts, from 'some.dts':
      Duration: 02:02:33.16, start: 0.000000, bitrate: 1535 kb/s
    Stream #0.0: Audio: dca (DTS-ES), 48000 Hz, 7 channels (FL|FR|FC|LFE|BC|SL|SR), s16, 1536 kb/s
[ac3 @ 0x101801800] channel_layout not specified
[ac3 @ 0x101801800] No channel layout specified. The encoder will guess the layout, but it might be incorrect.
Output #0, ac3, to 'some.ac3':
  Metadata:
    encoder         : Lavf53.4.0
    Stream #0.0: Audio: ac3, 48000 Hz, 5.1, s16, 448 kb/s
Stream mapping:
  Stream #0.0 -> #0.0
Press [q] to stop, [?] for help
Input stream #0.0 frame changed from rate:48000 fmt:s16 ch:7 to rate:48000 fmt:s16 ch:6
size=  409322kB time=02:04:44.73 bitrate= 448.0kbits/s    
video:0kB audio:409322kB global headers:0kB muxing overhead 0.000000%

real    6m26.944s
user    4m4.838s
sys 0m33.878s

Might be insignificant and limited by the disk throughput, though. However, it saves you at least from building aften (and possibly even libdca). On a Mac, MKVToolNIX can be grabbed precompiled (Mkvtoolnix -> Show Package Content -> Contents/MacOS, copy binaries to /usb/local/bin or whereever), so can ffmpeg (http://ffmpegmac.net/). rsync is AFAIR already shipped with Mac OS X. This is much more convenient and does not require Xcode at all.

I made some minor improvements to the original patch, btw (FFMPEG=0 as default, check for aften only when --ffmpeg is not specified): http://pastebin.ca/2092535

[d4nyl0]

Hi,

There is another issue which could encourage the maintainer to adopt this patch in the mainstream; see here:
http://www.legendiary.at/2011/10/01/dts2ac3-revisited/

[JakeWharton]

Thanks for your work on this. I will try to take a look at getting this implemented in the next few weeks as I agree that it offers many improvements.

[choekstr]

I did some testing and this seems to work quite well. If my testing is correct, we would just need to replace:
nice -n $PRIORITY dcadec -o $AUDIOMODE "$DTSFILE" 2>&1 /dev/null| nice -n $PRIORITY aften -v 0 - "$AC3FILE"
with
nice -n $PRIORITY ffmpeg -i "$DTSFILE" -acodec ac3 -ac 6 -ab 448k "$AC3FILE"

and change the checkdep from dcadec and aften to ffmpeg:
checkdep ffmpeg

[JakeWharton]

Done in dev branch. Would appreciate if some people would test. I won't be able to until this weekend-ish.

[choekstr]

Seems to work on the few files I tested but the output is so darn verbose. And of course insert appropriate bitching about how ffmpeg doesn't follow normal conventions (no quiet mode, no progress, all output is STDERR for some reason, -vstats doesn't work for audio, etc) I had to do some extra work to get the output into a sane format.

'-v 0' is supposed to quiet the output. It doesn't.
'- loglevel quiet' helps some but not enough.

Here is what we could use for the line to provide just a bit of feedback but strip out all the crap it insists on displaying:

    nice -n $PRIORITY ffmpeg -loglevel quiet -i "$DTSFILE" -acodec ac3 -ac 6 -ab 448k "$AC3FILE" 2>&1 |grep -vE "lib|Stream"

This loses the progress bar but gets rid of all the ffmpeg default crud. I am working on a slick way of getting a progress bar without any of the ffmpeg output. It is looking promising...

[gamontecarlo]

The only hypothetical issue which could arise is whether ffmpeg can process DTS without prior installation of libdca, I was too lazy to test that as we all have it installed already.

[choekstr]

ooh, good thought process. I just removed libdca-utils and libdca0 and aften from my system and I couldn't see anything wrong and it created a valid file that checks out on my normal set of sanity checks.

I don't see any issues but then again those wacky OSX guys always come back with something we never think of. ;)

[guy2545]

This has to be just me, but when I attempt to run the updated script ffmpeg throws an error when trying to convert dts to ac3. Says the fps of stream 0 does not match, 47.95 >- 23.9. If I run mkvextract and have it pull out both the h.264 video and dts and then run the dts through ffmpeg it works just fine.

[choekstr]

what is the mkvextract command you are using and what is the ffmpeg command. Maybe the params we use are not optimal or there are better switches to use? Since we use mkvextract and ffmpeg to convert the process is the same, it must be the specifics that are the difference.

[guy2545]

Seems with the recent commit I no longer have this issue. Please disregard. Thanks!

[codex22]

With the latest version (awk output), I get the same message as guy2545 about not matching fps.

[codex22]

Ok, the message is not telling about the real problem. Unfiltered, ffmpeg says "Output file #0 does not contain any stream", which in my case is caused by the fact that it's not the audio stream that got extracted, but the video stream!

[codex22]

Sorry for swamping this issue, but I know now what's going on.

I installed a new version of the MKVToolnix GUI, which comes with command line executables reporting version 5.2.0. This version reports different track numbers than before!

Installing and using the latest version from MacPorts (5.0.1), and all is well again!

[choekstr]

I will work on getting 5.2 installed and seeing if we can use a single cmdline for the old and new versions. I would hate to have to put version checking into the script and run different cmdlines based on which version is installed.

I know on my 10.04 LTS Ubuntu I am stuck at 5.0.1 for automatic updating. I would imagine for quite some time we will have people with varying versions of mkvtoolnix suite and can't really mandate a particular version unless there is no other way. I will try to find another way...

In the meantime everyone should use <5.1 or older mkvtoolnix

[guy2545]

Ah that explains it, I am running 5.2 on Ubuntu 11.10. What worked for me was to modified the mkvextract line to pull both the DTS track and the video track out (similar to the line below). Once I did that, I could pass the DTS track through ffmpeg and it would not complain about frame rates not matching. It works, but I don't know if it is the right way to do it.

mkvextract tracks input.mkv 1:video.h264 2:audio.dts

[choekstr]

Ok, setup an ubuntu 11.10 install so I could use mkvtoolnix 5.2 and sure enough, they have switched the numbering scheme from 0-n to 1-n in mkvextract BUT NOT IN mkvmerge. WTF?!?

So an example is:

File 'test.mkv': container: Matroska
Track ID 0: video (V_MPEG4/ISO/AVC)
Track ID 1: audio (A_DTS)

$ mkvextract tracks test.mkv 0:video.mpeg4
Error: No track with the ID 0 was found in the source file.

Off to see if there is a bug filed for this and if not file one. This isn't the correct behavior.

[choekstr]

There IS a bug filed for this and it has already been fixed in the code and will be pushed out in 5.3 version.

So the short answer is: Don't use mkvtoolnix 5.2 as it has a serious bug that breaks mkvdts2ac3.sh
If you want you can compile the committed git version of mkvtoolnix or go back to 5.1 or 5.0.1.

[choekstr]

mkvtoolnix 5.2.1 is out and tested to work correctly in Ubuntu 11.10. If you are having errors with mkvextract then update to the latest version.

I will leave this issue open for a while to ensure mkvextract plus the new ffmpeg method works for everyone and there are no more issues uncovered.

[JakeWharton]

Released as 1.6.0