Fabian Greffrath <fab...@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: ser...@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. :-)
