Recherche avancée

Sur d’autres sites (5243)

• How the ffmpeg astats crest factor is calculated

  30 août 2017, par FranGar

  I’m scripting a ffmpeg chain process for my work. The aim is normalizing/compressing lot of audio files (mp3’s).
  It’s done in Python and the critical part is the line :

  ffmpeg -y -i "Input.mp3" -codec:a libmp3lame -b:a 96k -af acompressor=threshold=-15dB:ratio=5:attack=0.01:release=1000:knee=2,dynaudnorm=g=3:m=2:p=0.95 "Output.mp3"

  The python script it’s complete and working BUT the nature of the audios (voice recordings) are very different so I can’t use the same params for all of them.

  I make some experimenting with the values of the ffmpeg filter astats and i discovered that the crest factor (Standard ratio of peak to RMS level ) gave a good reference to programatically get the better params.

  In fact I saw that a recording with a nice dynamic range sound and smooth in shape, get crest values around 9-15 (the compress/normlz params will be somehow conservative). But audios with crest around 22-30 need more aggressive processing.
  (All empirically)

  Somebody can clarify how the crest values are really calculated ? Which are the peaks taken to account ? (Why the flat factor is always 0 ?)
  Or if somebody knows how to get a value representing the sound ’smoothness’ will be nice also.

  Thanks for the ideas.

• avcodec/cbs_av1 : fix array size for ar_coeffs_cb_plus_128 and ar_coeffs_cr_plus_128

  11 décembre 2019, par James Almer

  avcodec/cbs_av1 : fix array size for ar_coeffs_cb_plus_128 and ar_coeffs_cr_plus_128
  Taking into account the code
  fb(2, ar_coeff_lag) ;
  
  num_pos_luma = 2 * current->ar_coeff_lag * (current->ar_coeff_lag + 1) ;
  
  if (current->num_y_points)
  
      num_pos_chroma = num_pos_luma + 1 ;
  
  else
  
      num_pos_chroma = num_pos_luma ;
  Max value for ar_coeff_lag is 3 (two bits), for num_pos_luma 24, and for
  
  num_pos_chroma 25.
  Both ar_coeffs_cb_plus_128 and ar_coeffs_cr_plus_128 may have up to
  
  num_pos_chroma values.
  Reviewed-by : Ronald S. Bultje <rsbultje@gmail.com>
  
  Signed-off-by : James Almer <jamrial@gmail.com>
  

  • [DH] libavcodec/cbs_av1.h

• Proper reading of MP3 file disrupted by ID3 tags

  3 septembre 2016, par PookyFan

  My semestral project is due this Thursday and I have major problem with reading MP3 file (the project is about sound analysis, don’t ask my what exactly is it about and why I’m doing it so late).

  First, I read first 10 bytes to check for ID3 tags. If they’re present, I’ll just skip to the first MP3 header - or at least that’s the big idea. Here is how I count ID3 tag size :

  if (inbuf[0] == 'I' && inbuf[1] == 'D' && inbuf[2] == '3') //inbuf contains first 10 bytes from file
  
  {
  
      int size = inbuf[3] * 2097152 + inbuf[4] * 16384 + inbuf[5] * 128 + inbuf[6]; //Will change to binary shifts later
  
      //Do something else with it - skip rest of ID3 tags etc
  
  }

  It works ok for files without ID3 tags and for some files with them, but for some other files ffmpeg (which I use for decoding) returns "no header" error, which means it didn’t catch MP3 header correctly. I know that since if I remove ID3 from that .mp3 file (with Winamp for example), no errors occur. The conclusion is that size count algorithm isn’t always valid.

  So the question is : how do I get to know how big exactly is entire ID3 part of the .mp3 file (all possible tags, album picture and whatever) ? I’m looking for it everywhere but I just keep finding this algorithm I posted above. Sometimes also something about some 10 bytes footer I need to take into account, but it seems it frequently gets more than 10 bytes for it to eventually catch proper MP3 frame.