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

[Sergio]

Fabian Greffrath <fabian at greffrath.com> wrote:

> Am 01.12.2010 12:09, schrieb Sergio:
>
>  "File larger than allowed for WAV files, may play truncated!"
>> So it seems like to be a WAV format limitation...
>>
> [...]
>
>  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.
>>
>
> The question is, what shall we do with this bug report then, if the cause
> is really simply a limitation in the WAV header format?


Yes, I've searched the web for info on wav format - it is a well known
problem with WAVes (among other numerous problems). Wav's size is limited
twice, as both RIFF container's size field and RIFF-WAV data-chunk size
field are uint32. More over, people say due to number of badly implemented
software, real limitation often is half of theoretical - near 2GiB due to
mistakenly used by programmers signed int for data size variables.
So this bug (or feature) is the global problem with WAVes - and common sound
processing problem as long as WAVes are used as universal interchange sound
format. There are known alternatives like BWF and RF64, "partially
compatible" with original WAVs, but the first uses "linked" files, the
second uses one big file with chunked data. I think, until some
wav-replacement format is commonly accepted, the easiest solution would be
just allow sound processing programs to ignore datasize specified in header
on user request - this definitely means "to use broken RIFF-WAV files". (Or
use raw datastream of course, though this requires to pass format
information by hand.)
Anyway, it is not suitable place to discuss the so wide problem.
Bug with size may be renamed to feature, but warning somewhere in manpage or
stderr output is desireable of course.

Some words about mplayer: when it has finished to write too large file, it
prints warning; if file is randomly-accessable, mplayer rewinds and puts
"almost maximum" (a bit smaller than 4GiB) value into RIFF and WAV-data
headers; if file is not (output sent to pipe), mplayer prints another
additional warining and the file rests with "initial default values" those
are "almost safe-maximum" (a bit smaller than 2GiB).

Here we can see, WAVes are really wrong choice for "universal sound format",
as the format originally was not designed for streaming and sending data
through pipes. "Datastream size" has to be written to file header but it is
often unknown at time of writing, WAV specs allows formatspec-chunk and
data-chunk go in any order and so on...


>         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.
>>
>
> Regarding this "bug"... IIRC dcadec just blabbers to stdout and this is
> redirected to some file via the ">" operator by the shell. Isn't it then the
> shell's duty to handle the file operator (so there isn't much dcadec can do)
> or am I missing something?
>
>
As far as I know, shell forks, sets up file handles as needed and execs
program, program uses these "inherited" redirected filehandles directly. It
may check file type, rewind it if it is of randomly-accessable type, close
and so on, output is not "piped to target file through shell process". So it
is the program's business to check for success with file ops.

$ dcadec -o wavall audio-rus-mvo-6ch.dts  > dummy-6ch.wav  2> /dev/null  &
# push to background
[1] 666
$ ps
  PID TTY          TIME CMD
  666 pts/1    00:00:02 dcadec
  667 pts/1    00:00:00 ps
 3093 pts/1    00:00:00 bash
$ ls -l /proc/666/fd/1
l-wx------ 1 sergio sergio 64 Дек  6 17:27 /proc/666/fd/1 ->
/mnt/data/dummy-6ch.wav
$

I made a look into sources, operation return code or stream state are simply
not checked after calls to fwrite in libao/audio_out_wav.c in wav_play and
wav_close functions.


And by the way one more minor-minor-minor problem:

sergio at bagira:~/wrk/dcadec/libdca-0.0.5$ LC_ALL=en  iconv -t UTF32LE
AUTHORS  > /dev/null
iconv: illegal input sequence at position 899

- Latin1 non-ASCII character stays in sources' AUTHORS file since the Dark
Ages I suppose. ;-) Common problem for various Debian "description"
textfiles. It's not a bug, but - really to perform distro-wide cleaning of
such artefacts would be good action. :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20101206/7778a020/attachment-0001.htm>