29 ноября 2010 г. 11:26 пользователь Fabian Greffrath <[email protected]>написал:
> Am 26.11.2010 21:30, schrieb Sergio: > >> 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. >> > > That's indeed an intersting question. Maybe files of these dimensions > simply exceed the specifications (or expectations) of a WAV file. > I've dived in mplayer's labyrinths... It's possible to get 6ch wav file from 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. > 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. >> > > 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? > 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: >> 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. > > - Fabian >
