Recherche avancée

Sur d’autres sites (9805)

• Detecting the value scale of statistics returned from ffprobe

  15 septembre 2023, par Farski

  I'm using ffprobe to detect max and min levels for various audio files. An example of the command I'm using is :

  


  ffprobe -v error -f lavfi -i amovie=my_song.mp3,asetnsamples=n=4410,astats=metadata=1:reset=1 -show_entries frame_tags=lavfi.astats.Overall.Max_level,lavfi.astats.Overall.Min_level -of json

  


  The max/min level values returned use different scales, depending on the format of the input file.

  


  For example, an MP3 file may return fractional values from -1.0 to 1.0 representing a percent of maximum level. A signed 16 bit WAV file returns values in the range -32,768 to 32767. A signed 32 bit FLAC file uses the range -2,147,483,648 to 2,147,483,647. In these cases, the bit size of the values matches the bit depth of the audio file.

  


  In other cases, such as a signed 8 bit WAV file, the results are returned using a scale that does not match the input file, such as 16 bit scale (-32,768 to 32767).

  


  I'm trying to determine if there's anyway to detect which format or scale ffprobe is using when the results are returned, besides trying to do it heuristically. I haven't been able to find any other value that gets returned which specifically reflects the number system being used to generate these levels values. sample_fmt does, in some cases, match, but in cases such as a s8 WAV file, sample_fmt would return s8, which does not match the number format of the returned levels values (s16).

  


  If it's not possible to request this information from ffprobe JIT, is there anywhere in the code base that would describe how it determines which scale to use ?

  


• How can i decode an mp3 and encode it as aac with ezstream

  8 avril 2015, par Roberto Arosemena

  This is my current ezstream config

  <ezstream>
  
     <url>http://localhost:8000/test</url>
  
     <sourcepassword>password</sourcepassword>
  
     <format>MP3</format>
  
     <filename>playlist.m3u</filename>
  
     <reencode>
  
        <enable>1</enable>
  
        <encdec>
  
           <format>MP3</format>
  
           <match>.mp3</match>
  
           <decode>madplay -b 16 -R 44100 -S -o raw:- "@T@"</decode>
  
           <encode>lame --preset cbr 32 -r -s 44.1 --bitwidth 16 - -</encode>
  
        </encdec>
  
     </reencode>
  
  </ezstream>

  It’s mounting to an icecast server, its decoding and encoding mp3 to a lower bitrate, I’m trying to encode it to aac instead of mp3 in hopes that the quality improves as i heard that aac is better than mp3 for lower bitrates.

  What i would like to know is if i can use an aac encoder such as FFmpeg instead of the lame mp3 encoder and get an aac to the end user instead of mp3, if so what parameters should i pass to FFmpeg so that it works with my current config.

• Anomalie #2855 : mauvais traitement du signe par textwheel

  9 août 2014, par cedric -

  Coquille dans le test, corrigée par http://zone.spip.org/trac/spip-zone/changeset/84111
  Si on dit que les < doivent être échappés dans la mesure du possible, le patch suivant semble faire le boulot sans casser aucun autre test.
  Mais est-ce que ça en vaut vraiment la peine ?

  Index : wheels/spip/spip.yaml
  ===================================================================
  
  — - wheels/spip/spip.yaml       (revision 83994)
  +++ wheels/spip/spip.yaml       (working copy)
  @@ -183,3 +183,9 @@
     match : ["\x1\x1", "\x1\x2", "\x1\x3", "\x1\x4"]
     replace : [’’, ’’, ’_’, ’-’]
     type : str
  +
  +echapg-—chevron-ouvrant :
  +  #if_str : "
  &lt;script&quot; <br />
  
  +  type: preg<br />
  
  +  match: &quot;/&lt;([^&gt;&lt;]*)(?=&lt;|$)/Uims&quot; <br />
  
  +  replace: &quot;&amp;amp;lt;$1&quot; <br />
  
  &lt;/pre&gt;