Recherche avancée

Sur d’autres sites (8068)

• Python - why do I get this ffprobe error ?

  4 juillet 2022, par gasper101

  I am on mac and am working on a project in which my program shoud convert a .mp3 file into a .wav file and than get text from that file (basic speech recognition). For converting a .mp3 file into a .wav file I am using ffmpeg library. I have installed both ffmpeg and ffprobe libraryies using pip and than using homebrew so I have them installed in a folder.

  


  This is my code :

  


  import speech_recognition
from pydub import AudioSegment
from os import path


#get text from original voice file------------------------------------------------- 

sound = AudioSegment.from_mp3("/path/to/file.mp3")
sound.export("/output/path/file.wav", format="wav")

file_audio = speech_recognition.AudioFile('/output/path/file.wav')

r = speech_recognition.Recognizer()
with file_audio as source:
    audio_text = r.record(source)

word = r.recognize_google(audio_text)


  


  And this is the error i get :
FileNotFoundError : [Errno 2] No such file or directory : 'ffprobe'

  


  Full error :
Warning (from warnings module) :
File "/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/pydub/utils.py", line 170
warn("Couldn't find ffmpeg or avconv - defaulting to ffmpeg, but may not work", RuntimeWarning)
RuntimeWarning : Couldn't find ffmpeg or avconv - defaulting to ffmpeg, but may not work

  


  Warning (from warnings module) :
File "/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/pydub/utils.py", line 198
warn("Couldn't find ffprobe or avprobe - defaulting to ffprobe, but may not work", RuntimeWarning)

  


  RuntimeWarning : Couldn't find ffprobe or avprobe - defaulting to ffprobe, but may not work
Traceback (most recent call last) :
File "/Users/marcus/Downloads/pronaunciation_checker/pronaunciation_check.py", line 12, in 
sound = AudioSegment.from_mp3("/Users/marcus/Desktop/think.mp3")
File "/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/pydub/audio_segment.py", line 796, in from_mp3
return cls.from_file(file, 'mp3', parameters=parameters)
File "/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/pydub/audio_segment.py", line 728, in from_file
info = mediainfo_json(orig_file, read_ahead_limit=read_ahead_limit)
File "/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/pydub/utils.py", line 274, in mediainfo_json
res = Popen(command, stdin=stdin_parameter, stdout=PIPE, stderr=PIPE)
File "/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/subprocess.py", line 951, in init
self._execute_child(args, executable, preexec_fn, close_fds,
File "/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/subprocess.py", line 1821, in _execute_child
raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError : [Errno 2] No such file or directory : 'ffprobe'

  


• ytdl python "KeyError : formats"

  7 juillet 2022, par Mondumkreisung

  Im trying to make a discord music bot for personal use, since groovy and rythm got shut down.
It's working okay-ish I guess, but im having a problem with ytdl.
typing "-play" and an url is working just like intended, but i cant type "-play 'song name'".
Typing "-play example" gives me this :

  


  [download] Downloading playlist: example
[youtube:search] query "example": Downloading page 1
[youtube:search] playlist example: Downloading 1 videos
[download] Downloading video 1 of 1
[youtube] CLXt3yh2g0s: Downloading webpage
Ignoring exception in command play:
[download] Finished downloading playlist: example
Traceback (most recent call last):
  File "C:\Users\Dennis\PycharmProjects\groovy's true successor\venv\lib\site-packages\discord\ext\commands\core.py", line 85, in wrapped
    ret = await coro(*args, **kwargs)
  File "C:\Users\Dennis\PycharmProjects\groovy's true successor\voice.py", line 53, in play
    url2 = info['formats'][0]['url']
KeyError: 'formats'

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "C:\Users\Dennis\PycharmProjects\groovy's true successor\venv\lib\site-packages\discord\ext\commands\bot.py", line 939, in invoke
    await ctx.command.invoke(ctx)
  File "C:\Users\Dennis\PycharmProjects\groovy's true successor\venv\lib\site-packages\discord\ext\commands\core.py", line 863, in invoke
    await injected(*ctx.args, **ctx.kwargs)
  File "C:\Users\Dennis\PycharmProjects\groovy's true successor\venv\lib\site-packages\discord\ext\commands\core.py", line 94, in wrapped
    raise CommandInvokeError(exc) from exc
discord.ext.commands.errors.CommandInvokeError: Command raised an exception: KeyError: 'formats'


  


  im fairly new to coding, so im sorry if somethings weird to understand.

  


  okay, so : typing -play with an url works fine, but typing -play with the song name doesnt. its only searching for the first word, downloads the first searchresult and then "crashes".

  


  so "-play Rick Astley - Never Gonna Give You Up" for example only searches for "Rick" and then it says something about KeyError : 'formats'
Here is my code :

  


  @client.command()
async def play(ctx, url):
    channel = ctx.author.voice.channel
    voice = discord.utils.get(client.voice_clients, guild=ctx.guild)
    if voice and voice.is_connected():
        pass
    else:
        await channel.connect()

    ffmpeg_opts = {'before_options': '-reconnect 1 -reconnect_streamed 1 -reconnect_delay_max 5', 'options': '-vn'}
    ydl_opts = {'format': "bestaudio/best", 'default_search': 'auto'}
    vc = ctx.voice_client

    with youtube_dl.YoutubeDL(ydl_opts) as ydl:
        info = ydl.extract_info(url, download=False)
        url2 = info['formats'][0]['url']
        source = await discord.FFmpegOpusAudio.from_probe(url2, **ffmpeg_opts)
        vc.play(source)


  


• Greed is Good ; Greed Works

  25 novembre 2010, par Multimedia Mike — VP8

  Greed, for lack of a better word, is good ; Greed works. Well, most of the time. Maybe.

  Picking Prediction Modes
  VP8 uses one of 4 prediction modes to predict a 16x16 luma block or 8x8 chroma block before processing it (for luma, a block can also be broken into 16 4x4 blocks for individual prediction using even more modes).

  So, how to pick the best predictor mode ? I had no idea when I started writing my VP8 encoder. I did not read any literature on the matter ; I just sat down and thought of a brute-force approach. According to the comments in my code :

  // naive, greedy algorithm :
  //   residual = source - predictor
  //   mean = mean(residual)
  //   residual -= mean
  //   find the max diff between the mean and the residual
  // the thinking is that, post-prediction, the best block will
  // be comprised of similar samples
  

  After removing the predictor from the macroblock, individual 4x4 subblocks are put through a forward DCT and quantized. Optimal compression in this scenario results when all samples are the same since only the DC coefficient will be non-zero. Failing that, when the input samples are at least similar to each other, few of the AC coefficients will be non-zero, which helps compression. When the samples are all over the scale, there aren’t a whole lot of non-zero coefficients unless you crank up the quantizer, which results in poor quality in the reconstructed subblocks.

  Thus, my goal was to pick a prediction mode that, when applied to the input block, resulted in a residual in which each element would feature the least deviation from the mean of the residual (relative to other prediction choices).

  Greedy Approach
  I realized that this algorithm falls into the broad general category of "greedy" algorithms— one that makes locally optimal decisions at each stage. There are most likely smarter algorithms. But this one was good enough for making an encoder that just barely works.

  Compression Results
  I checked the total file compression size on my usual 640x360 Big Buck Bunny logo image while forcing prediction modes vs. using my greedy prediction picking algorithm. In this very simple test, DC-only actually resulted in slightly better compression than the greedy algorithm (which says nothing about overall quality).

  prediction mode	quantizer index = 0 (minimum)	quantizer index = 10
  greedy	286260	98028
  DC	280593	95378
  vertical	297206	105316
  horizontal	295357	104185
  TrueMotion	311660	113480

  As another data point, in both quantizer cases, my greedy algorithm selected a healthy mix of prediction modes :

  • quantizer index 0 : DC = 521, VERT = 151, HORIZ = 183, TM = 65
  • quantizer index 10 : DC = 486, VERT = 167, HORIZ = 190, TM = 77

  Size vs. Quality
  Again, note that this ad-hoc test only measures one property (a highly objective one)— compression size. It did not account for quality which is a far more controversial topic that I have yet to wade into.