*** Please type your report below this line ***

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.

Example:
I have extracted DTS audio track from .mkv movie container using
mkvextract. Now:

$ ls -l audio-rus-mvo.dts
-rw-r--r-- 1 sergio sergio 614424560 Ноя 26 17:13 audio-rus-mvo.dts

Well, ~600 MiB DTS.

$ mediainfo audio-rus-mvo.dts
General
Complete name                    : audio-rus-mvo.dts
Format                           : DTS
Format/Info                      : Digital Theater Systems
File size                        : 586 MiB
Duration                         : 1h 48mn
Overall bit rate                 : 754 Kbps

Audio
Format                           : DTS
Format/Info                      : Digital Theater Systems
Duration                         : 1h 48mn
Bit rate mode                    : Constant
Bit rate                         : 754 Kbps
Channel(s)                       : 6 channels
Channel positions                : Front: L C R, Side: L R, LFE
Sampling rate                    : 48.0 KHz
Bit depth                        : 24 bits
Stream size                      : 586 MiB (100%)

Duration of 1:48 reported. Converting it to multitrack wav:

$ dcadec -o wavall audio-rus-mvo.dts  > audio-rus-mvo-6ch.wav

And so I got 7.5 GiB 6channel wav (that seems to be correct size for
6ch 32bit/sample 1:48 sound):

$ ls -l audio-rus-mvo-6ch.wav
-rw-r--r-- 1 sergio sergio 7505018948 Ноя 26 17:27 audio-rus-mvo-6ch.wav

It seems to be really 6ch wav as I can judge looking at spectrogram.
And its duration reported correctly by mediainfo:

$ mediainfo /mnt/sys_10/alice-audio-rus-mvo-6ch.wav
General
Complete name                    :
/mnt/sys_10/alice-audio-rus-mvo-6ch.wav
Format                           : Wave
File size                        : 6.99 GiB
Duration                         : 1h 48mn
Overall bit rate                 : 9 216 Kbps

Audio
ID                               : 0
Format                           : PCM
Format profile                   : Float
Format settings, Endianness      : Float
Codec ID                         : 00001000-0000-0300-8000-00AA00389B71
Codec ID/Hint                    : IEEE
Duration                         : 1h 48mn
Bit rate mode                    : Constant
Bit rate                         : 9 216 Kbps
Channel(s)                       : 6 channels
Channel positions                : Front: L C R, Back: L R, LFE
Sampling rate                    : 48.0 KHz
Bit depth                        : 32 bits
Stream size                      : 6.99 GiB (100%)

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.

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.

Am 26.11.2010 21:30, schrieb Sergio:

That's indeed an intersting question. Maybe files of these dimensions
simply exceed the specifications (or expectations) of a WAV file.

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?

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

29 ноября 2010 г. 11:26 пользователь Fabian Greffrath
<fabian@greffrath.com>написал:
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.

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:

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:
[...]

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?

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.

It probably uses another version of libao internally.

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

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

Fabian Greffrath <fabian@greffrath.com> wrote:
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...
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@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. :-)

Sergio,

thank you for your detailed investigation.

Am 06.12.2010 17:00, schrieb Sergio:

I think the same. Let's summarize and agree that this bug report
request two features:

- Add the ability to export raw, headerless WAV data
- Check the output stream for possible errors

Well, I wouldn't even consider this worth a patch. ;)

Thanks again!

  - Fabian