<br><br><div class="gmail_quote">29 ÎÏÑÂÒÑ 2010šÇ. 11:26 ÐÏÌØÚÏ×ÁÔÅÌØ Fabian Greffrath <span dir="ltr">&lt;<a href="mailto:fabian@greffrath.com">fabian@greffrath.com</a>&gt;</span> ÎÁÐÉÓÁÌ:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Am 26.11.2010 21:30, schrieb Sergio:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
dcadec produces WAV files, that are reported as are much shorter, than<br>
expected to be, but are big enough to contain sound of full duration.<br>
Either dcadec produces broken files, or files are valid but no one<br>
is able to read them correctly.<br>
</blockquote>
<br>
That&#39;s indeed an intersting question. Maybe files of these dimensions simply exceed the specifications (or expectations) of a WAV file.<br></blockquote><div>š</div><div>I&#39;ve dived in mplayer&#39;s labyrinths... It&#39;s possible to get 6ch wav file from DTS audiotrack with mplayer using command like this:<br>
<br>š $ mplayer -channels 6 -aid 0 -ao pcm:file=audio0-6ch.wav -vc dummy -vo null video.mkv<br><br>In this case with 2:58 video, mplayer wrote ~6GiB s16LE wav file, and printed when finished:<br>&quot;File larger than allowed for WAV files, may play truncated!&quot;<br>
So it seems like to be a WAV format limitation...<br>
This time, playable length is reported by sox as &quot;Duration: 02:04:16.53&quot;.<br>Or converting to 6-ch float samples, like dcadec does:<br><br>š $ mplayer -channels 6 -format floatle -aid 0 -ao pcm:fast:file=audio0-6ch.wav -vc dummy -vo null video.mkv<br>
<br>This time I got ~12GiB wav with: &quot;Duration: 01:02:08.27&quot;<br>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.<br>
Finally I can convert to so called &quot;raw&quot; headerless PCM with:<br><br>š $ mplayer -channels 6 -format floatle -aid 0 -ao pcm:nowaveheader:fast:file=audio0-6ch.floatle.raw -vc dummy -vo null video.mkv<br><br>And use with:<br>
<br>š $ sox -t raw -c 6 -r 48k -L -e floating-point -b 32 audio0-6ch.floatle.raw -d<br><br>&quot;Duration: 02:58:14.97&quot;<br><br>So I understand I can get usable &quot;wav&quot; soundtrack if I trim wav header from dcadec output to get &quot;raw&quot; data?..<br>
If it is really WAV format limitation, it would be nice to have &quot;raw&quot;, &quot;rawdolby&quot;, &quot;raw6&quot;, &quot;rawall&quot; 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 &quot;length&quot; value and just read data until EOF. <br>
I&#39;m afraid, a52dec may share this problem with large WAVs. For somewhat reason it doesn&#39;t support wavall and wav6 output at all.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
But when I try to play file with:<br>
 š rhytmbox<br>
 š mplayer<br>
 š totem<br>
 š sox<br>
all of them see file duration 0:46:26. (sox says: Duration: 00:46:26.50)<br>
I have seen the same result with another extracted-DTS-to-6ch-wav<br>
conversion, in that case sound was torn in some other wrong duration.<br>
The same result if writing to pipe.<br>
</blockquote>
<br>
I don&#39;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?<br>
</blockquote><div><br>mediainfo as I see is from debian-multimedia reps:<br>š deb <a href="http://www.debian-multimedia.org">http://www.debian-multimedia.org</a> lenny main<br>š deb <a href="http://www.debian-multimedia.org">http://www.debian-multimedia.org</a> squeeze main<br>
š deb <a href="http://www.debian-multimedia.org">http://www.debian-multimedia.org</a> sid main<br>š <a href="http://www.debian-multimedia.org/pool/main/m/mediainfo/">http://www.debian-multimedia.org/pool/main/m/mediainfo/</a><br>
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?.. <br><br>š $ mkvextract tracks video.mkv 2:audio.dts<br>š $ dcadec -o wavall audio.dtsš &gt; audio.wav<br>
š $ file audio.wav <br>š audio.wav: RIFF (little-endian) data, WAVE audio, 6 channels 48000 Hz<br><br>file doesn&#39;t tell sound file length for WAVs... may be more modern versions do.<br>ffprobe in my installation prints some error with libraries on start and nothing more.<br>
ffplay plays something, shows correct duration of 2:58:+, but its &quot;interface&quot; looks too vogue to understand. :)<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
In addition to this one, there is error with output-error handling:<br>
in case of running out of disk space (that is very possible with<br>
so giant WAVs) no error reported, no error status returned, and<br>
decoding process continues to nowhere.<br>
</blockquote>
<br>
Alright, that&#39;s a completely different issue (and certainly worth its own bug report) and I&#39;ll try to have a look at it sooner or later.<br><font color="#888888">
<br>
š- Fabian<br>
</font></blockquote></div><br>