Recherche avancée

Sur d’autres sites (7106)

• UnsupportedAudioFileException in LIUM Speaker Diarization after re-sampling

  14 septembre 2016, par RAVI D PARIKH

  I am trying to configure LIUM tool for speaker diarization. This question is a follow up of UnsupportedAudioFileException in LIUM Speaker Diarization

  I have tried re sampling the file using sox and ffmpeg

  I am new to any sorts of programming and i have followed all steps described in LIUM quick start guide and the above link. I still get the same error. I think my input file has issues related to header as mentioned by Nikolay Shmyrev in the above link however i have no clue on how to solve it.

  My code is as below :

  java –jar  C:\Users\Ravi\Desktop\LIUM_SpkDiarization-8.4.1.jar \ --fInputMask= C:\Users\Ravi\Desktop\converted_f2.wav--sOutputMask= C:\Users\Ravi\Desktop\converted_converted_2.seg -–help --doCEClustering

  Error :

  10:52.037 SEVERE AudioFeatureSetFa  FileNotFoundException
  
  java.io.FileNotFoundException:
  
          at java.io.FileInputStream.open0(Native Method)
  
          at java.io.FileInputStream.open(Unknown Source)
  
          at java.io.FileInputStream.<init>(Unknown Source)
  
          at com.sun.media.codec.audio.mp3.JS_MP3FileReader.getAudioFileFormat(JS_MP3FileReader.java:82)
  
          at javax.sound.sampled.AudioSystem.getAudioFileFormat(Unknown Source)
  
          at fr.lium.spkDiarization.libFeature.AudioFeatureSetFactory.getAudio(AudioFeatureSetFactory.java:162)
  
          at fr.lium.spkDiarization.libFeature.AudioFeatureSetFactory.MakeFeature(AudioFeatureSetFactory.java:207)
  
  </init>

  The input file is at https://drive.google.com/file/d/0B7Fqe9EX5JbgT09BcXpSREd4em8/view?usp=sharing

  Input File Name:converted_f2.wav

  I have put the command and the full output of the prompt in a word document at

  https://drive.google.com/file/d/0B7Fqe9EX5JbgUUl6THNCZFgxRnM/view?usp=sharing

  The inpiut file has correct sampling rate and other parameters and thus i am not able to understand the cause of the error.
  Thanks a lot for the help

  Regards,
  Ravi

• How to redirect -progress option output of ffmpeg to stderr ?

  27 janvier 2019, par gerrBen

  I’m writing my own wraping for ffmpeg on Python 3.7.2 now and want to use it’s "-progress" option to read current progress since it’s highly machine-readable. The problem is "-progress" option of ffmpeg accepts as its parameter file names and urls only. But I don’t want to create additional files not to setup the whole web-server for this purpose.

  I’ve google a lot about it, but all the "progress bars for ffmpeg" projects rely on generic stderr output of ffmpeg only. Other answers here on Stackoverflow and on Superuser are being satisfied with just "-v quiet -stats", since "progress" is not very convenient name for parameter to google exactly it’s cases.

  The best solution would be to force ffmpeg write it’s "-progress" output to separate pipe, since there is some useful data in stderr as well regarding file being encoded and I don’t want to throw it away with "-v quiet". Though if there is a way to redirect "-progress" output to stderr, it would be cool as well ! Any pipe would be ok actually, I just can’t figure out how to make ffmpeg write it’s "-progress" not to file in Windows. I tried "ffmpeg -progress stderr ...", but it just create the file with this name.

• Anomalie #3250 (Nouveau) : Les liens dans une autre langue devraient respecter les conventions ty...

  28 juillet 2014, par 毎日 erational -

  Exemple sur un site français / anglais.
  On a un article anglais qui s’appelle "Do you like Mangoes ?" (pas d’espace entre Mangoes et ?, règles typographiques anglaises).
  Si depuis un article français, je fais un lien interne vers cet article, [->75], le titre apparait comme "Do you like Mangoes ?" (avec un espace, règles typographiques françaises alors que l’anglaise devrait s’appliquer)

  Idem si on pinaille, si on fait un lien en précisant la langue
  [Would you to visit Google?|{en}->http://www.google.com] depuis un article français, il serait sans doute pertinent d’appliquer les règles typographiques de la langue cible.

  En attendant on peut toujours tricher en remplaçant les ? par le code HTML &h63; qui évite le traitement typo :p