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

[Fabian Greffrath]

retitle 605052 libdca-utils: please allow raw WAV output modes
severity 605052 wishlist
thanks

Hi Sergio,

thank you very much for your investigation.

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?

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

Alright, so I have just retitled this report. However, there isn't 
much I can do about the other "various sound processing programs" that 
rely on the header information.

> I'm afraid, a52dec may share this problem with large WAVs. For
> somewhat reason it doesn't support wavall and wav6 output at all.

It probably uses another version of libao internally.

> ffprobe in my installation prints some error with libraries on start
> and nothing more.

Most probably due to mixing of ffmpeg libraries with the ones from d-m.o.

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

  - Fabian