Recherche avancée

Sur d’autres sites (10221)

• swresample/dither : Cleanup number suffixes

  1er février 2015, par Michael Niedermayer

  swresample/dither : Cleanup number suffixes
  The <<31 case needs LL
  Signed-off-by : Michael Niedermayer <michaelni@gmx.at>
  

  • [DH] libswresample/dither.c

• configure : don’t generate a git version number if .git isn’t present

  4 septembre 2013, par Sean McGovern

  configure : don’t generate a git version number if .git isn’t present
  

  • [DH] version.sh

• How to compute the number of extra samples added by LAME or FFMPEG

  24 janvier 2018, par actuallyaswin

  I am attempting to build a MP3 decoder / parser in Python which supports files encoded by LAME or FFMPEG.

  My encoding shell script is shown here :

  #!/bin/bash
  
  for i in wav/*.wav; do
  
      i=${i##*/};
  
      lame --nores --strictly-enforce-ISO -t --cbr -b 64 -h "wav/${i}" "mpeg/lame/${i%.wav}.mp3";
  
      ffmpeg -i "wav/${i}" -codec:a libmp3lame -qscale:a 2 "mpeg/ffmpeg/${i%.wav}.mp3";
  
  done

  This scripts reads WAVE files located in ./wav/ and produces a controlled-bitrate MP3 of 64kbps in my ./mp3/lame/ directory, and a variable-bitrate MP3 of quality 2 in my ./mp3/ffmpeg/.

  I have written a Python script that iterates through both resultant MP3s, counting the number of frames and samples. Both the LAME and FFMPEG results are equivalent (in terms of frames and samples), but their binary files are different.

  The LAME/FFMPEG sample count was done by iterating through the binary MP3 files, locating and parsing the frame header, then using the MP3 spec to determine the number of samples per frame.

  • Number of MP3 data-frames : 112 (ignoring the Xing/Info first frame)
  • Number of output frames : 112*576 = 64512

  Here is a comparison of the sample count for a single 4-second input file :

  • Input WAV # of samples = 62996
  • Output LAME/FFMPEG # of samples = 64512
  • Difference = 1516

  I understand that according to the LAME FAQ file, resultant MP3 files are zero padded in the front and back to make sure the inverse MDCT is performed properly, but also because the windows overlap.

  What I can’t ascertain from the above FAQ, or from any previous StackOverflow post, is how to compute the number of artificially added samples. If I can be sure that all 1516 of these samples are zeros, and I can be sure of their position in the bytestream, I’d like to be able to confidently toss them out. Since there are 1516 "extra" samples and there are 576 samples per frame for a V2LIII encoding, then there must be more than two (but less than three) erroneous MPEG frames here.

  Is anyone here savvy enough with MPEG encoding/decoding to know how many samples are added, and in which frames those samples will be in ? In other words, will the first frame and last frame always contain blank data, or are there more frames ?