[issue1595] FLAC decoder fails with large silent chunks.
Justin Ruggles justin.rugg...@gmail.com added the comment: I don't think anything is wrong here. You're getting weird audio output because you're using --sign=unsigned. In unsigned audio, 0 is full negative amplitude. flac -d foo.flac -o foo_flac.wav ffmpeg -i foo.flac foo_lavc.wav cmp foo_flac.wav foo_lavc.wav The results are identical. No issue. -- status: open - closed substatus: needs_more_info - invalid _ FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/roundup/ffmpeg/issue1595 _
[issue1595] FLAC decoder fails with large silent chunks.
Deiz ffm...@pwnly.com added the comment: I didn't realize --unsigned was what was causing the output issue (As it turns out, that's dmix mixing the 0 dB sample with other output.) but that's not the underlying issue. I have a copyrighted file (which I'm not going to upload) which is prepended by 10 minutes of silence, and then contains roughly a minute of audio. When I play the FLAC with ffplay or mplayer, bad things happen. For example, seeking with ffplay results in Seek to 43% (-247034:-20:-58) of total duration (-577014:-32:-22). Seek errors seem to be common with all files, but if I play a WAV of the same track, it outputs a sane amount: Seek to 38% ( 0:04:14) of total duration ( 0:11:01) Does ffmpeg differentiate between decoding to disk and decoding for use by audio devices? The fact that no FFmpeg-using application is able to play the FLAC tells me something's wrong. -- status: closed - open substatus: invalid - _ FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/roundup/ffmpeg/issue1595 _
[issue1595] FLAC decoder fails with large silent chunks.
Justin Ruggles justin.rugg...@gmail.com added the comment: Deiz wrote: Deiz ffm...@pwnly.com added the comment: I didn't realize --unsigned was what was causing the output issue (As it turns out, that's dmix mixing the 0 dB sample with other output.) but that's not the underlying issue. I have a copyrighted file (which I'm not going to upload) which is prepended by 10 minutes of silence, and then contains roughly a minute of audio. When I play the FLAC with ffplay or mplayer, bad things happen. For example, seeking with ffplay results in Seek to 43% (-247034:-20:-58) of total duration (-577014:-32:-22). Seek errors seem to be common with all files, but if I play a WAV of the same track, it outputs a sane amount: Seek to 38% ( 0:04:14) of total duration ( 0:11:01) Does ffmpeg differentiate between decoding to disk and decoding for use by audio devices? The fact that no FFmpeg-using application is able to play the FLAC tells me something's wrong. Can't play or can't seek? There is a big difference. If it can't play/decode, what errors are you getting? Is the decoded output different from the input? _ FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/roundup/ffmpeg/issue1595 _
[issue1595] FLAC decoder fails with large silent chunks.
Justin Ruggles justin.rugg...@gmail.com added the comment: needs more info. as Carl said, please supply complete output of the ffmpeg command that leads to this failure. -- substatus: - needs_more_info _ FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/roundup/ffmpeg/issue1595 _
[issue1595] FLAC decoder fails with large silent chunks.
Deiz ffm...@pwnly.com added the comment: I'm not 100% certain that ffplay is failing to play the track, as it does not echo pertinent information to stdout, even with -debug. mplayer and VLC, however, are both able to play WAVs generated by separately decoding the FLAC with ffmpeg or libflac, yet fail with the FLAC itself. ffmpeg -i foo.flac foo2.wav, edited so as to not make this page miles long: FFmpeg version 0.5, Copyright (c) 2000-2009 Fabrice Bellard, et al. configuration: --prefix=/usr --enable-gpl --enable-libmp3lame --enable-libvorbis --enable-libfaac --enable-libfaad --enable-libxvid --enable-libx264 --enable-libtheora --enable-postproc --enable-shared --enable-pthreads --enable-x11grab --enable-swscale libavutil 49.15. 0 / 49.15. 0 libavcodec52.20. 0 / 52.20. 0 libavformat 52.31. 0 / 52.31. 0 libavdevice 52. 1. 0 / 52. 1. 0 libswscale 0. 7. 1 / 0. 7. 1 libpostproc 51. 2. 0 / 51. 2. 0 built on Apr 18 2009 20:24:32, gcc: 4.3.3 Input #0, flac, from 'foo.flac': Duration: N/A, bitrate: N/A Stream #0.0: Audio: flac, 44100 Hz, stereo, s16 Output #0, wav, to 'foo2.wav': Stream #0.0: Audio: pcm_s16le, 44100 Hz, stereo, s16, 1411 kb/s Stream mapping: Stream #0.0 - #0.0 Press [q] to stop encoding Multiple frames in a packet from stream 0 [Trimmed, as the above line repeats 2448 times] [flac @ 0x19a4d80]FRAME HEADER not here size= 40960kB time=237.77 bitrate=1411.2kbits/s video:0kB audio:40960kB global headers:0kB muxing overhead 0.000105% The seek time in ffplay may be indicative of something. Regardless of input size (I tried 40 1MB blocks, 20, and 5), the seek time reported is always similar to this: Seek to 42% (-241624:-50:-18) of total duration (-577014:-32:-22), reporting the same total duration regardless of filesize. While ffplay cannot play either the dd-sourced file or my local file with a hidden track, mplayer reacts in a different manner. With the dd-sourced file, it terminates instantly (EOF). With the hidden track file, it seems to hang when decoding a frame, and seeking causes the decoder to completely skip the ten minutes of silence, moving directly to the audio. As ffplay provides no pertinent information, I've pastebinned mplayer's debug output, as it contains ffmpeg-related lines: http://pastebin.ca/1704873 -- substatus: needs_more_info - _ FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/roundup/ffmpeg/issue1595 _
[issue1055] WMAv2 decoding artifacts
Michael Niedermayer michae...@gmx.at added the comment: Regression fixed in r20756. [...] -- status: open - closed substatus: reproduced - fixed _ FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/roundup/ffmpeg/issue1055 _
[issue1596] Add support for IFF 16SV audio format
New submission from ami_stuff ami_st...@o2.pl: This is like IFF 8SVX, but 16bit (libsndfile support it). This is the new 16 bit IFF sound format on Amiga. From the basic concept, it is a 8SVX file, but the BODY chunk consists of 16 bit. Not (yet?) supported are compression, multi octave, attack/sustain and sequences. By the way: this is the only 16 bit format supporting loops. The 16SV format is based on the 8SVX format. All chunk types exist, but values in the chunks (e.g. in VHDR) always refer to samples and not to offsets (i.e. Bytes). So you have to multiply loop start by two to get the real starting offset in the BODY chunk. Additionally, the file type is 16SV instead of 8SVX. The BODY chunk contains samples in word width, using the Motorola notation (MSB,LSB). Stereo samples are stored with all left channel's samples first, followed by all right channel's samples. It is important that samples are always stored using 16 bit resolution. If you e.g. sampled using 12 bit, you have to rotate the samples to 16 bit (asl #4,d0) before saving. The only disadvantage is that programs which only support 8SVX format, cannot read these files; even loaded as RAW they seem to contain no sense. Furthermore, a Stereo sample is not stored samplewise left/right, so playback of large samples from hard disk is not possible without time consuming seeks. C:\ffmpeg.exe -i DolbySample.16SV FFmpeg version SVN-r20746, Copyright (c) 2000-2009 Fabrice Bellard, et al. built on Dec 6 2009 06:06:23 with gcc 4.2.4 configuration: --enable-memalign-hack --prefix=/mingw --cross-prefix=i686-ming w32- --cc=ccache-i686-mingw32-gcc --target-os=mingw32 --arch=i686 --cpu=i686 --e nable-avisynth --enable-gpl --enable-version3 --enable-zlib --enable-bzlib --ena ble-libgsm --enable-libfaad --enable-pthreads --enable-libvorbis --enable-libthe ora --enable-libspeex --enable-libmp3lame --enable-libopenjpeg --enable-libxvid --enable-libschroedinger --enable-libx264 --enable-libopencore_amrwb --enable-li bopencore_amrnb libavutil 50. 5. 1 / 50. 5. 1 libavcodec52.42. 0 / 52.42. 0 libavformat 52.41. 0 / 52.41. 0 libavdevice 52. 2. 0 / 52. 2. 0 libswscale 0. 7. 2 / 0. 7. 2 DolbySample.16SV: Unknown format File 'DolbySample.16SV' not attached - you can download it from https://roundup.ffmpeg.org/roundup/ffmpeg/file641. -- files: DolbySample.16SV messages: 8198 priority: normal status: new substatus: new title: Add support for IFF 16SV audio format type: feature_request _ FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/roundup/ffmpeg/issue1596 _
[issue1595] FLAC decoder fails with large silent chunks.
Justin Ruggles justin.rugg...@gmail.com added the comment: Well, it's hard to tell anything without a sample. Can you at least attach the foo.ana file output from flac -a foo.flac and the output of metaflac --list foo.flac? _ FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/roundup/ffmpeg/issue1595 _
[issue1595] FLAC decoder fails with large silent chunks.
Deiz ffm...@pwnly.com added the comment: metaflac --list foo.flac: METADATA block #0 type: 0 (STREAMINFO) is last: false length: 34 minimum blocksize: 4096 samples maximum blocksize: 4096 samples minimum framesize: 14 bytes maximum framesize: 16 bytes sample_rate: 44100 Hz channels: 2 bits-per-sample: 16 total samples: 10485760 MD5 signature: ec8bb3b24d5b0f1b5bdf8c8f0f541ee6 METADATA block #1 type: 3 (SEEKTABLE) is last: false length: 432 seek points: 24 point 0: sample_number=0, stream_offset=0, frame_samples=4096 point 1: sample_number=438272, stream_offset=1498, frame_samples=4096 point 2: sample_number=880640, stream_offset=3097, frame_samples=4096 point 3: sample_number=1318912, stream_offset=4702, frame_samples=4096 point 4: sample_number=1761280, stream_offset=6322, frame_samples=4096 point 5: sample_number=2203648, stream_offset=7942, frame_samples=4096 point 6: sample_number=2641920, stream_offset=9547, frame_samples=4096 point 7: sample_number=3084288, stream_offset=11167, frame_samples=4096 point 8: sample_number=3526656, stream_offset=12787, frame_samples=4096 point 9: sample_number=3964928, stream_offset=14392, frame_samples=4096 point 10: sample_number=4407296, stream_offset=16012, frame_samples=4096 point 11: sample_number=4849664, stream_offset=17632, frame_samples=4096 point 12: sample_number=5287936, stream_offset=19237, frame_samples=4096 point 13: sample_number=5730304, stream_offset=20857, frame_samples=4096 point 14: sample_number=6172672, stream_offset=22477, frame_samples=4096 point 15: sample_number=6610944, stream_offset=24082, frame_samples=4096 point 16: sample_number=7053312, stream_offset=25702, frame_samples=4096 point 17: sample_number=7495680, stream_offset=27322, frame_samples=4096 point 18: sample_number=7933952, stream_offset=28927, frame_samples=4096 point 19: sample_number=8376320, stream_offset=30547, frame_samples=4096 point 20: sample_number=8818688, stream_offset=32272, frame_samples=4096 point 21: sample_number=9256960, stream_offset=33984, frame_samples=4096 point 22: sample_number=9699328, stream_offset=35712, frame_samples=4096 point 23: sample_number=10141696, stream_offset=37440, frame_samples=4096 METADATA block #2 type: 4 (VORBIS_COMMENT) is last: false length: 40 vendor string: reference libFLAC 1.2.1 20070917 comments: 0 METADATA block #3 type: 1 (PADDING) is last: true length: 8192 File 'foo.ana' not attached - you can download it from https://roundup.ffmpeg.org/roundup/ffmpeg/file642. _ FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/roundup/ffmpeg/issue1595 _
[issue1595] FLAC decoder fails with large silent chunks.
Justin Ruggles justin.rugg...@gmail.com added the comment: That foo.ana file indicates that your source is all silence. So I recreated the file and could not reproduce any issues with ffmpeg or ffplay from SVN. Update to latest SVN and see if you can reproduce any issues with ffmpeg or ffplay. -- substatus: - open _ FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/roundup/ffmpeg/issue1595 _
[issue1595] FLAC decoder fails with large silent chunks.
Deiz ffm...@pwnly.com added the comment: Playing works with latest ffplay/ffmpeg from SVN, seek does not (but seek fails with normal files, too, so it's outside the scope of this report). With ffmpeg compiled from latest SVN, other applications still fail to play the file; I assume the individual implementations introduce more room for error. In any case, it appears this bug is fixed, at least on the FFmpeg side of things. _ FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/roundup/ffmpeg/issue1595 _
[issue1595] FLAC decoder fails with large silent chunks.
Justin Ruggles justin.rugg...@gmail.com added the comment: there is already an open issue about flac seeking. closing this issue. -- status: open - closed substatus: open - invalid _ FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/roundup/ffmpeg/issue1595 _
