Bug#605052: libdca-utils: dcadec produces broken WAVs

[Sergio]

29 ноября 2010 г. 11:26 пользователь Fabian Greffrath
<fabian at greffrath.com>написал:

> Am 26.11.2010 21:30, schrieb Sergio:
>
>> dcadec produces WAV files, that are reported as are much shorter, than
>> expected to be, but are big enough to contain sound of full duration.
>> Either dcadec produces broken files, or files are valid but no one
>> is able to read them correctly.
>>
>
> That's indeed an intersting question. Maybe files of these dimensions
> simply exceed the specifications (or expectations) of a WAV file.
>

I've dived in mplayer's labyrinths... It's possible to get 6ch wav file from
DTS audiotrack with mplayer using command like this:

  $ mplayer -channels 6 -aid 0 -ao pcm:file=audio0-6ch.wav -vc dummy -vo
null video.mkv

In this case with 2:58 video, mplayer wrote ~6GiB s16LE wav file, and
printed when finished:
"File larger than allowed for WAV files, may play truncated!"
So it seems like to be a WAV format limitation...
This time, playable length is reported by sox as "Duration: 02:04:16.53".
Or converting to 6-ch float samples, like dcadec does:

  $ mplayer -channels 6 -format floatle -aid 0 -ao
pcm:fast:file=audio0-6ch.wav -vc dummy -vo null video.mkv

This time I got ~12GiB wav with: "Duration: 01:02:08.27"
So duration is about 2/3 of real length for 6GiB and 1/3 for 12GiB, looks
like wav headers use uint32 to store data stream size counted in bytes.
Finally I can convert to so called "raw" headerless PCM with:

  $ mplayer -channels 6 -format floatle -aid 0 -ao
pcm:nowaveheader:fast:file=audio0-6ch.floatle.raw -vc dummy -vo null
video.mkv

And use with:

  $ sox -t raw -c 6 -r 48k -L -e floating-point -b 32 audio0-6ch.floatle.raw
-d

"Duration: 02:58:14.97"

So I understand I can get usable "wav" soundtrack if I trim wav header from
dcadec output to get "raw" data?..
If it is really WAV format limitation, it would be nice to have "raw",
"rawdolby", "raw6", "rawall" output modes in dcadec (and warning for
wav-output somewhere). It would also be nice to have option in various sound
processing programs that would force them to ignore wave header "length"
value and just read data until EOF.
I'm afraid, a52dec may share this problem with large WAVs. For somewhat
reason it doesn't support wavall and wav6 output at all.


>  But when I try to play file with:
>>   rhytmbox
>>   mplayer
>>   totem
>>   sox
>> all of them see file duration 0:46:26. (sox says: Duration: 00:46:26.50)
>> I have seen the same result with another extracted-DTS-to-6ch-wav
>> conversion, in that case sound was torn in some other wrong duration.
>> The same result if writing to pipe.
>>
>
> I don't know the mediainfo tool (it does not seem to be available from the
> Debian archive), but I guess that the aforementioned packages all pretty
> much share their WAV-decoding code. What does the file(1) utility say (what
> does ffmpeg say) and what happens if you put the WAV file back into a
> container, say MKV or OGG?
>

mediainfo as I see is from debian-multimedia reps:
  deb http://www.debian-multimedia.org lenny main
  deb http://www.debian-multimedia.org squeeze main
  deb http://www.debian-multimedia.org sid main
  http://www.debian-multimedia.org/pool/main/m/mediainfo/
May be it just ignores wav header length and read file data until EOF when
it sees the file is too large, and calculates duration time from file
size?..

  $ mkvextract tracks video.mkv 2:audio.dts
  $ dcadec -o wavall audio.dts  > audio.wav
  $ file audio.wav
  audio.wav: RIFF (little-endian) data, WAVE audio, 6 channels 48000 Hz

file doesn't tell sound file length for WAVs... may be more modern versions
do.
ffprobe in my installation prints some error with libraries on start and
nothing more.
ffplay plays something, shows correct duration of 2:58:+, but its
"interface" looks too vogue to understand. :)

 In addition to this one, there is error with output-error handling:
>> in case of running out of disk space (that is very possible with
>> so giant WAVs) no error reported, no error status returned, and
>> decoding process continues to nowhere.
>>
>
> Alright, that's a completely different issue (and certainly worth its own
> bug report) and I'll try to have a look at it sooner or later.
>
>  - Fabian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20101201/5d3faa00/attachment.htm>