#4717 closed enhancement (fixed)
ffprobe fails to get Monkey's Audio sample size
Reported by: | ahthovaikied | Owned by: | |
---|---|---|---|
Priority: | wish | Component: | avcodec |
Version: | git-master | Keywords: | ape |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
Take any Monkey's Audio file, it is reproducible with any MA file, but for the sake of example:
$ rsync rsync://fate-suite.libav.org/fate-suite/lossless-audio/luckynight-mac394b1-c2000.ape test.ape
Probe it:
$ ./ffprobe -show_format -show_streams test.ape ffprobe version N-73616-gfeb6a94 Copyright (c) 2007-2015 the FFmpeg developers built with gcc 4.8 (Ubuntu 4.8.4-2ubuntu1~14.04) configuration: --enable-gpl --enable-version3 --enable-nonfree --disable-runtime-cpudetect --disable-ffserver --disable-encoder=vorbis --disable-encoder=aac --enable-x11grab --enable-libfdk-aac --enable-libmp3lame --enable-libopus --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxvid --disable-debug --cpu=corei7 libavutil 54. 28.100 / 54. 28.100 libavcodec 56. 47.100 / 56. 47.100 libavformat 56. 40.100 / 56. 40.100 libavdevice 56. 4.100 / 56. 4.100 libavfilter 5. 21.100 / 5. 21.100 libswscale 3. 1.101 / 3. 1.101 libswresample 1. 2.100 / 1. 2.100 libpostproc 53. 3.100 / 53. 3.100 Input #0, ape, from 'test.ape': Duration: 00:01:00.48, start: 0.000000, bitrate: 43 kb/s Stream #0:0: Audio: ape (APE / 0x20455041), 44100 Hz, stereo, s16p [STREAM] index=0 codec_name=ape codec_long_name=Monkey's Audio profile=unknown codec_type=audio codec_time_base=1/44100 codec_tag_string=APE codec_tag=0x20455041 sample_fmt=s16p sample_rate=44100 channels=2 channel_layout=stereo bits_per_sample=0 id=N/A r_frame_rate=0/0 avg_frame_rate=0/0 time_base=1/44100 start_pts=0 start_time=0.000000 duration_ts=2667168 duration=60.480000 bit_rate=N/A max_bit_rate=N/A bits_per_raw_sample=N/A nb_frames=37 nb_read_frames=N/A nb_read_packets=N/A DISPOSITION:default=0 DISPOSITION:dub=0 DISPOSITION:original=0 DISPOSITION:comment=0 DISPOSITION:lyrics=0 DISPOSITION:karaoke=0 DISPOSITION:forced=0 DISPOSITION:hearing_impaired=0 DISPOSITION:visual_impaired=0 DISPOSITION:clean_effects=0 DISPOSITION:attached_pic=0 [/STREAM] [FORMAT] filename=test.ape nb_streams=1 nb_programs=0 format_name=ape format_long_name=Monkey's Audio start_time=0.000000 duration=60.480000 size=328000 bit_rate=43386 probe_score=100 [/FORMAT]
Given this previous ticket https://trac.ffmpeg.org/ticket/3919#comment:5, I expected bits_per_raw_sample
to be 16
.
Change History (7)
comment:1 by , 10 years ago
Component: | ffprobe → avcodec |
---|---|
Priority: | normal → wish |
Type: | defect → enhancement |
follow-up: 3 comment:2 by , 10 years ago
From your comment in the other ticket I thought sample_fmt was only the internal sample representation used by FFmpeg, and that actual sample size could be anything below that.
If not, can you confirm that the right algorithm to reliably extract sample size is:
if value of 'bits_per_sample' > 0: return value of 'bits_per_sample' else if value of 'bits_per_raw_sample' is set: return value of 'bits_per_raw_sample' else extract sample size from 'sample_fmt' string
It looks complex for such simple task but I am looking for something reliable that works for every audio format on the surface of the earth.
Thanks
comment:3 by , 10 years ago
Replying to ahthovaikied:
From your comment in the other ticket I thought sample_fmt was only the internal sample representation used by FFmpeg, and that actual sample size could be anything below that.
Below or equal, yes.
But I don't think anything with 8<bits_per_raw_sample<16 exists and since developers are lazy, they did not implement anything related yet.
comment:4 by , 10 years ago
Why not making bits_per_raw_sample
always available if it is different from bits_per_sample
?
comment:6 by , 4 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:7 by , 4 years ago
Keywords: | ape added |
---|
Replying to ahthovaikied:
bits_per_raw_sample is important for 24bit files because there is no other way to know they are 24bit. If the audio format is s16p, such a disambiguation should not be necessary.