Python library for audio and music analysis

Overview

librosa

A python package for music and audio analysis.

PyPI Anaconda-Server Badge License DOI

Build Status Build status Coverage Status

Documentation

See https://librosa.org/doc/ for a complete reference manual and introductory tutorials.

Installation

The latest stable release is available on PyPI, and you can install it by saying

pip install librosa

Anaconda users can install using conda-forge:

conda install -c conda-forge librosa

To build librosa from source, say python setup.py build. Then, to install librosa, say python setup.py install. If all went well, you should be able to execute the demo scripts under examples/ (OS X users should follow the installation guide given below).

Alternatively, you can download or clone the repository and use pip to handle dependencies:

unzip librosa.zip
pip install -e librosa

or

git clone https://github.com/librosa/librosa.git
pip install -e librosa

By calling pip list you should see librosa now as an installed package:

librosa (0.x.x, /path/to/librosa)

Hints for the Installation

librosa uses soundfile and audioread to load audio files. Note that soundfile does not currently support MP3, which will cause librosa to fall back on the audioread library.

soundfile

If you're using conda to install librosa, then most audio coding dependencies (except MP3) will be handled automatically.

If you're using pip on a Linux environment, you may need to install libsndfile manually. Please refer to the SoundFile installation documentation for details.

audioread and MP3 support

To fuel audioread with more audio-decoding power (e.g., for reading MP3 files), you may need to install either ffmpeg or GStreamer.

Note that on some platforms, audioread needs at least one of the programs to work properly.

If you are using Anaconda, install ffmpeg by calling

conda install -c conda-forge ffmpeg

If you are not using Anaconda, here are some common commands for different operating systems:

  • Linux (apt-get): apt-get install ffmpeg or apt-get install gstreamer1.0-plugins-base gstreamer1.0-plugins-ugly
  • Linux (yum): yum install ffmpeg or yum install gstreamer1.0-plugins-base gstreamer1.0-plugins-ugly
  • Mac: brew install ffmpeg or brew install gstreamer
  • Windows: download binaries from this website

For GStreamer, you also need to install the Python bindings with

pip install pygobject

Discussion

Please direct non-development questions and discussion topics to our web forum at https://groups.google.com/forum/#!forum/librosa

Citing

If you want to cite librosa in a scholarly work, there are two ways to do it.

  • If you are using the library for your work, for the sake of reproducibility, please cite the version you used as indexed at Zenodo:

    DOI

  • If you wish to cite librosa for its design, motivation etc., please cite the paper published at SciPy 2015:

    McFee, Brian, Colin Raffel, Dawen Liang, Daniel PW Ellis, Matt McVicar, Eric Battenberg, and Oriol Nieto. "librosa: Audio and music signal analysis in python." In Proceedings of the 14th python in science conference, pp. 18-25. 2015.

Comments
  • Multirate Filterbank from Chroma Toolbox

    Multirate Filterbank from Chroma Toolbox

    Hi everyone,

    following #394, this is a first start on integrating the multirate filterbank which is used in the chroma toolbox.

    I have another notebook where I show the whole processing chain: https://github.com/stefan-balke/mpa-exc/blob/master/02_fourier_transform/pitch_filterbank.ipynb

    As for implementation, it could live as another "spectral representation" in spectrum.py, although its more a CQT–but I guess we leave cqt.py reserved for the actual transform. Parameter-wise, this one is pretty much fixed, although one could add a parameter for "detuning", meaning another reference frequency than 440 Hz @ A4.

    But that's up for discussion.

    As next steps, I would add some unit tests comparing the filter coefficients to the Chroma Toolbox and a function which actually calls this filterbank...should be straight-forward!


    This change is Reviewable

    enhancement functionality 
    opened by stefan-balke 89
  • DTW

    DTW

    Hey all,

    I mainly took @craffel dijtw source code and merged it with mine. As dicussed in #298, we want the following features:

    • [x] Arbitrary step sizes
    • [x] Additive or multiplicative local weights for the steps
    • [x] Subsequence (so it can be used for matching)
    • [x] Global path constraints (e.g. Sakoe-Chiba band etc.)
    • [x] make numba optional (cf. Brian's comment)
    • [x] test backtracking explicitly
    • [x] plot D + wp (in the examples)
    • ~~Gullying~~

    After finishing the features (which are in dijtw), we need more tests and some final notebook with benchmarking the implementation against "vanilla-vanilla" dtw.


    This change is Reviewable

    functionality 
    opened by stefan-balke 84
  • The big Multi-Channel PR

    The big Multi-Channel PR

    Reference Issue

    This PR begins the work of #1130, extending librosa to support multi-channel wherever possible.

    What does this implement/fix? Explain your changes.

    This branch will serve as the target for smaller pull requests implementing multi-channel support throughout the package.

    As a first step, I've implemented multi-channel stft. It's numerically equivalent to our previous implementation, and comparably efficient for single-channel inputs. For multi-channel inputs, it's not as efficient as I think is possible, but optimization will take a bit of sleuthing.

    Any other comments?

    This PR will not be merged until #1130 is complete.


    Progress tracker

    beat

    • [x] tempo : yes, one tempo per channel?
    • [x] plp : yes

    decompose

    • [x] decompose : maybe, could require some clever reshaping. not obvious how to do it.
    • [x] hpss : yes
    • [x] nn_filter : features: probably, self-similarity: ~probably not~ no

    effects

    • [x] hpss : yes
    • [x] harmonic : yes
    • [x] percussive : yes
    • [x] time_stretch : yes
    • [x] pitch_shift : yes (issue #1085)
    • [x] preemphasis: yes
    • [x] deemphasis: yes
    • [x] trim
    • [x] split
    • [x] remix : yes update: zc alignment won't be feasible here, but we can only support zc alignment for mono signals.

    filters

    ~- [ ] diagonal_filter: could require some thought~ - not necessary; this is mainly used for building smoothing filters for self-similarity matrices, which in the multi-channel case, would still operate independently across channels. Keeping diagonal filters 2d seems appropriate.

    onset

    • [x] onset_strength: yes
    • [x] onset_strength_multi: yes ~- [ ] onset_backtrack: probably not~ no

    segment

    • [x] cross_similarity : and
    • [x] recurrence_matrix : yes-ish: channels dimensions are flattened so output integrates over channels ~- [ ] recurrence_to_lag~ : no ~- [ ] lag_to_recurrence~ : no ~- [ ] timelag_filter : maybe~ nothing to do here, as it depends entirely on lag<->recurrence conversion
    • [x] path_enhance: yes

    sequence

    • [x] dtw : probably best to treat similarly to segment modules: flatten channel dimensions ~- [ ] rqa : not really; ragged output. otherwise, treat like dtw~ rqa takes a square matrix as input; nothing to do here
    • [x] viterbi : yes
    • [x] viterbi_discriminative : yes
    • [x] viterbi_binary : yes

    core

    • [x] stream: n/a, I think?
    • [x] to_mono: yes
    • [x] resample: yes, n/a
    • [x] get_duration: yes
    • [x] stft: yes
    • [x] istft: yes
    • [x] magphase : yes
    • [x] griffinlim: yes
    • [x] zero_crossings: yes
    • [x] autocorrelate: yes
    • [x] fmt: yes
    • [x] pcen: yes
    • [x] cqt: yes
    • [x] vqt: yes
    • [x] pseudo_cqt: yes
    • [x] hybrid_cqt: yes
    • [x] icqt: yes
    • [x] griffinlim_cqt: yes
    • [x] reassigned_spectrogram: yes
    • [x] phase_vocoder: yes
    • [x] interp_harmonics: yes ~- [ ] harmonics_1d: yes~ -> remove, fold functionality into interp_harmonics ~- [ ] harmonics_2d: yes~ -> remove
    • [x] salience: yes
    • [x] iirt: yes
    • [x] lpc: yes
    • [x] yin: yes
    • [x] piptrack: yes
    • [x] estimate_tuning: yes ~should produce one tuning estimate per channel~ one tuning estimate across all channels ~- [ ] pitch_tuning: yes~ no, this works on a set of frequencies, not the signal directly. Nothing to do here.
    • [x] pyin: yes
    • [x] clicks: yes, but only if a multichannel click sample is provided ~- [ ] tone~: no

    feature

    • [x] chroma_stft: yes
    • [x] chroma_cqt: yes
    • [x] chroma_cens: yes
    • [x] melspectrogram: yes
    • [x] mfcc:yes
    • [x] rms: yes
    • [x] spectral_centroid: yes
    • [x] spectral_bandwidth: yes
    • [x] spectral_flatness: yes
    • [x] spectral_rolloff: yes
    • [x] poly_features : yes
    • [x] tonnetz : yes
    • [x] zero_crossing_rate : yes
    • [x] delta : yes
    • [x] stack_memory : yes
    • [x] tempogram : yes
    • [x] fourier_tempogram : yes
    • [x] mel_to_stft: yes
    • [x] mel_to_audio : yes
    • [x] mfcc_to_mel :yes
    • [x] mfcc_to_audio: yes

    util

    • [x] frame: yes
    • [x] pad_center: yes
    • [x] fix_length: yes
    • [x] softmask: yes
    • [x] normalize: yes
    • [x] localmax: yes
    • [x] localmin: yes
    • [x] valid_audio: yes
    • [x] stack: yes ~- [ ] fix_frames: probably not / nothing to do?~ ~- [ ] index_to_slice~: no - this is an inherently one-dimensional operation
    • [x] sync: yes, maybe already works ~- [ ] axis_sort: ~maybe, not clear what it would mean~ probably not; possible rename to axis_sort2d~ no ~- [ ] shear: maybe; dense only? but probably not~ no
    • [x] nnls: yes

    Maintenance tasks

    • [x] audit docstrings of all functions extended for multichannel
    • [x] expand_to helper function
    • [x] relax valid_audio shape checks
    • [x] audit for use of valid_audio
    enhancement functionality API change 
    opened by bmcfee 65
  • YIN and pYIN

    YIN and pYIN

    Reference Issue

    Fixes #527

    What does this implement/fix? Explain your changes.

    This pull request implements the YIN and pYIN algorithms for pitch tracking. The YIN function is based on @lostanlen's PR #974 (with a few modifications) while the pYIN function is based on this paper.

    Any other comments?

    Both functions work well but some refactoring is definately needed. I compared the outputs of pYIN to the official vamp plugin and the results are comparable. I haven't added any special treatment of low amplitude frames yet so silent frames with periodic noice occasionally give wrong results.

    Also, note that I haven't used the librosa.core.autocorrelate function. The librosa.core.autocorrelate computes equation (2) in the YIN paper which seems to perform worse than the one used here (which computes equation (1)). I tried scaling by the window size (as suggested in the paper) but it didn't improve things much.

    I haven't implemented any tests yet so it would be good to get some guidance there.

    functionality 
    opened by bshall 59
  • DTW

    DTW

    Hey there,

    I recently did a DTW implementation based on Meinard's book with some Cython speed up for the dynamic programming. As this is not yet reflected in librosa, I wondered if we could do a module for music syncronization.

    Best Stefan

    functionality discussion 
    opened by stefan-balke 45
  • CQT length scale normalization

    CQT length scale normalization

    This PR implements #412, and a couple of bug-fixes. Summary of contents:

    • Added a scale boolean option to all CQT methods. If enabled, CQT bands are normalized by sqrt(n[i]) where n[i] is the length of the ith filter. This is analogous to norm='ortho' mode in np.fft.fft.
    • Early downsampling is less aggressive by one octave. Previously, it was too aggressive, and the top-end of each octave was close to nyquist, which resulted in attenuation.
    • Magnitude is now continuous and approximately equal for full, hybrid, and pseudo CQT. This fixes some of the unresolved continuity errors noted in #347.
    • Expanded the CQT unit tests to include a white noise continuity test.

    Using scale=True means that white noise input will look like white noise output in CQT space (flat spectrum). With scale=False (current default), white noise in looks like 1/sqrt(f).

    scale=True makes an impulse look like sqrt(f) as opposed to constant for scale=False.


    This change is Reviewable

    bug enhancement functionality API change 
    opened by bmcfee 41
  • [Discussion] CQT, VQT, energy preservation, and frequency band alignment

    [Discussion] CQT, VQT, energy preservation, and frequency band alignment

    I wanted to make a separate issue to consolidate the discussion around a number of related points that have popped up in the implementation of VQT #1018, inverse CQT #165, and so on. @lostanlen and I have discussed these things in various places (often offline), but it would be helpful to have a more permanent record.

    Frequency band definitions

    In the CQT implementation, we follow the SK2010 definition of the frequency bands, which are essentially left-aligned: [f, a * f] (for some constant a). This works well enough, but it makes some calculations awkward, eg in the VQT. Later on in the CQT toolbox, the definition shifted to a centered representation, eg [f / sqrt(a), f * sqrt(a)] (again for some constant a), so that the frequency of each filter is centered within the band.

    Some questions:

    • Should we add support for centered frequency bands? I don't think it would change much, except possibly some boundary effects at the top end of octaves.
    • Should we make centering the default? Should we even bother with left-aligned bands anymore?

    Energy preservation

    Our CQT implementation has historically had a bunch of headaches around normalization and energy preservation. Of course we can't exactly preserve energy with a lossy frequency representation, but our current cqt/icqt round trip gets pretty close. However, other feature representations (notably Mel) are not so forgiving, and it would be nice if we could strive for consistency here.

    discussion 
    opened by bmcfee 37
  • Default sample rate for librosa.core.load is not the native sample rate

    Default sample rate for librosa.core.load is not the native sample rate

    Currently, the default sample rate is 22050 Hz when loading an audio file. In order to use the native sample rate, sr must be set to None. I often forget to set this to None when I want the native sample rate, and I have noticed many students do the same.

    Have others experienced confusion over this? Should this change in a later release so that the native sample rate is the default?

    discussion IO 
    opened by mcartwright 31
  • RFC: more example tracks?

    RFC: more example tracks?

    It's been mentioned on numerous occasions that our current example track, catchy as it may be, is not great for demonstrating many of the functions of librosa. In offline discussions, @lostanlen and I have talked about extending the included audio content to have several tracks, which could be used to demonstrate different functionality. So I want to kick this out to the community: what do you want to see in our examples? By this I mean: please recommend specific recordings.

    To prevent this discussion from becoming an infinite bike shed, I'm going to lay down some ground rules for inclusion:

    1. Content must be CC-licensed or public domain.
    2. Total content should not bloat the package too much; I think 10MB is a reasonable upper bound, and this functionally limits us to between 5 and 10 total recordings.
    3. No single track should be too long. It's okay to have some very short examples.
    4. The total collection should be diverse in terms of style, instrumentation, polyphony, etc. If possible, I'd like to include some non-western recordings as well.
    5. Any lyrical content should not be offensive, for some reasonable definition of offensive which is compatible with our CoC. I don't expect any problems here, but I'll reserve executive privilege here to veto anything that could be problematic.
    6. Familiarity would be a bonus, for making the examples and documentation more immediately accessible.

    With all of that out of the way, let's talk about things not currently demonstrated by our current example. We don't have to hit all of these, and I'm sure I'm missing some, but we should aim to hit most of them.

    • Monophonic audio: we should have at least one solo instrument recording that can be used to demonstrate things like pitch tracking. Maybe a raga or makam could be good here? This could also be good for demonstrating onsets.
    • Interesting harmony: the current example is pretty boring, harmonically speaking. Maybe a jazz recording would be appropriate here? Maybe something with some key changes as well.
    • Non-percussive rhythmic elements: something classical (strings) would be nice to have for demonstrating onset and beat tracking with soft attacks.
    • Different time signatures: examples with 4/4, 3/4, and maybe a 5/4 or 7/8 would be nice for demonstrating some of the rhythmic features (tempogram, fmt)
    • Vocals and instrumentals: we should have at least one track with vocals.
    • Non-musical audio: do we need/want this? Speech? Environmental sound? Librosa gets used for these things, so it might be worth considering their inclusion.

    Some other discussions that we can have around this:

    • Should we have a multi-track / stem set as one of the examples?
    • What kind of genre coverage should we strive for?
    • How does this issue interact with #641 (non-western systems in display)? Is #641 a pre-requisite for including non-western examples? (I'd argue that it should be, and that this would be a good motivating factor for finally doing it.)

    Finally, the examples gallery already includes a few candidate options here. We can take some, all, or none of these, but whatever we decide on including should serve as plausible replacements for them and the example notebooks should be revised afterward.

    discussion management 
    opened by bmcfee 30
  • Added optional pyFFTW backend

    Added optional pyFFTW backend

    As proposed in https://github.com/librosa/librosa/issues/353 scipy.fftpack is a terrible bottleneck and supporting FFTW would be immensely useful. This pull request adds an optional wrapper for FFTW. If pyFFTW is installed librosa will prefer that over scipy.fftpack. Everything will work as normal if the user is missing pyFFTW.

    @bmcfee, thoughts? The speedup is substantial, and as librosa depends on STFT all over the place (even for rmse) I feel this is a necessary addition, and a lot nicer than having users monkey patch outside of librosa.


    This change is Reviewable

    enhancement 
    opened by carlthome 30
  • No Backends

    No Backends

    When running the example I receive this error

    In[2]:
    
    import matplotlib, librosa
    In [3]:
    
    import IPython.display
    import numpy as np
    In [4]:
    
    import matplotlib.pyplot as plt
    %matplotlib inline
    In [12]:
    
    y, sr = librosa.load(librosa.util.example_audio_file())
    ---------------------------------------------------------------------------
    NoBackendError                            Traceback (most recent call last)
    <ipython-input-12-1c3f0c525dc9> in <module>()
    ----> 1 y, sr = librosa.load(librosa.util.example_audio_file())
    
    /Library/Python/2.7/site-packages/librosa/core/audio.pyc in load(path, sr, mono, offset, duration, dtype)
        106 
        107     y = []
    --> 108     with audioread.audio_open(os.path.realpath(path)) as input_file:
        109         sr_native = input_file.samplerate
        110 
    
    /Library/Python/2.7/site-packages/audioread/__init__.pyc in audio_open(path)
         94 
         95     # All backends failed!
    ---> 96     raise NoBackendError()
    
    NoBackendError: 
    

    Any Ideas as to what could be causing this? I am running the example in Ipython notebook and OSX Yosemite 10.10

    opened by dsiah 30
  • numpy 1.23 compatibility

    numpy 1.23 compatibility

    Describe the bug We appear to have some fancy-slicing errors with numpy 1.23. I'll fill in with more details once I have a bleeding edge test environment.

    bug 
    opened by bmcfee 0
  • [WIP] lazy imports

    [WIP] lazy imports

    Fixes #1523 , and #1184

    What does this implement/fix? Explain your changes.

    This PR implements lazy loading for faster imports, following the recent examples out of scipy and skimage and using the lazy_loader package.

    Quick demo of the benefits. Importing librosa before (current main branch):

    In [1]: %time import librosa
    CPU times: user 1.09 s, sys: 88.1 ms, total: 1.17 s
    Wall time: 1.19 s
    

    and after, with lazy loading:

    In [1]: %time import librosa
    CPU times: user 1.81 ms, sys: 151 µs, total: 1.96 ms
    Wall time: 1.21 ms
    

    As an additional benefit, we no longer have to separately import librosa.display! This is a big win for usability.

    Any other comments?

    A couple of things to be aware of here:

    1. lazy_loader is on pypi, but not yet on conda forge. We should hold off on merging until the packaging catches up.
    2. I've only implemented this at the top-level package import. I don't think there's much benefit to drilling down further to thread laziness throughout the package, but I could be persuaded otherwise.
    3. lazy loader does not like * imports, so the top-level __init__ now explicitly lists out each element being imported from core (and other submodules). This is probably a good thing, but it does mean that we need to explicitly update the top-level index any time we add or change a core function.
    enhancement blocked 
    opened by bmcfee 14
  • Deprecating librosa.load() default sr and mono

    Deprecating librosa.load() default sr and mono

    Is your feature request related to a problem? Please describe. Using librosa.load() without care will cause unexpected resampling and channel merging. It may silently spoil results. (It really happned :facepalm:)

    Describe the solution you'd like Change default of librosa.load() to

    librosa.load(..., sr=None, mono=False, ...)
    

    Describe alternatives you've considered

    1. Deprecate sr=22050, mono=True default, and add warning about default 22050Hz samplerate and mono merging.
    2. Remove default value of sr, mono in future release.
    3. Change default value to sr=None, mono=False in more future release

    something like

    def load(path, *, sr=-1, mono=-1, ...):
        if sr == -1:
            sr = 22050
            warnings.warn("Implicit default 22050Hz resampling is deprecated. Set samplerate in Hz to resample or use None to disable resampling.", DeprecationWarning)
    
        ...
    

    Additional context

    discussion 
    opened by dofuuz 3
  • Add type annotations

    Add type annotations

    I would like to have code completions and type checking for code that uses librosa. Adding type annotations will significantly improve the coding experience for users who use type checkers / typing-based completion engines.

    Currently some type checkers like Pylance are able to infer some types, however this is often wrong and leads to false positives (errors on working code) or false negatives (missing errors on invalid code). Other type checkers like Mypy cannot do anything with code that uses librosa, and must treat it as 'Any'.

    functionality 
    opened by matangover 5
  • Advanced example: sounddevice streaming

    Advanced example: sounddevice streaming

    Is your feature request related to a problem? Please describe.

    We somewhat often get questions about how to use librosa for stream-based processing of a live audio capture. The "PCEN Streaming" example gets us part of the way there, but it uses soundfile's block streaming mode and not a live device.

    Describe the solution you'd like We could add an example using the sounddevice package to do a frame- or block-based processing example with callbacks or asyncio.

    The main challenge in setting this up would be getting the documentation to build consistently offline. I wonder if there's a way that we could mock this in the documentation build to simulate having a live device?

    As a stretch goal, it would be great if the example could generate an animated display.

    documentation 
    opened by bmcfee 2
  • [WIP] Just intonation

    [WIP] Just intonation

    Reference Issue

    Fixes #1402

    What does this implement/fix? Explain your changes.

    This PR adds just intonation support in various places, as discussed extensively in #1402.

    Specifically:

    • [x] new submodule core.intervals for managing interval generation
    • [x] vqt(..., intervals=) allows users to specify non-ET systems
    • [x] core.notation adds converters for functional just system (FJS) representation
    • [x] display axis decorators support for JI frequency grids
    • [x] chroma_vqt to support chroma features derived from non-ET bases

    Any other comments?

    Some stretch goals for this PR:

    • [ ] advanced example illustrating how to use JI systems
      • [ ] if possible, also include a music21 scale→librosa interval set demo
    • [ ] package data file including pre-computed scales, especially sruti22
    • [ ] extend support for svara conversion to non-ET systems
    enhancement functionality 
    opened by bmcfee 10
Releases(0.9.2)
  • 0.9.2(Jun 27, 2022)

    What's Changed

    • updated showversions to match setup.cfg. fixes #1455 by @bmcfee in https://github.com/librosa/librosa/pull/1457
    • switched submodule url to https in advance of git:// deprecation by @bmcfee in https://github.com/librosa/librosa/pull/1461
    • Fix db_to_amplitude docs by @i-aki-y in https://github.com/librosa/librosa/pull/1469
    • Improved read me by @Asmitha-K in https://github.com/librosa/librosa/pull/1473
    • Expanded documentation for viterbi_discriminative by @bmcfee in https://github.com/librosa/librosa/pull/1475
    • Allow preconstructed audioread objects in load by @bmcfee in https://github.com/librosa/librosa/pull/1477
    • Improved edits to the README.md file by @cr2007 in https://github.com/librosa/librosa/pull/1479
    • Fix function name in docs of STFT by @LorenzNickel in https://github.com/librosa/librosa/pull/1487
    • pinned sphinx version to 4.5 for doc site by @bmcfee in https://github.com/librosa/librosa/pull/1491
    • bug-fix for multichannel splitting by @bmcfee in https://github.com/librosa/librosa/pull/1493
    • Remove redundant article in CONTRIBUTING.md by @LorenzNickel in https://github.com/librosa/librosa/pull/1507
    • Fix typo in warning in inverse.py by @LorenzNickel in https://github.com/librosa/librosa/pull/1508
    • Fix multiple typos in spectral.py by @LorenzNickel in https://github.com/librosa/librosa/pull/1509
    • Speed up magphase by @futurulus in https://github.com/librosa/librosa/pull/1504
    • Escape special characters in the directory paths when calling find_files() by @Xiao-Ming in https://github.com/librosa/librosa/pull/1511
    • Documentation updates ahead of 0.9.2 release by @bmcfee in https://github.com/librosa/librosa/pull/1513

    New Contributors

    • @i-aki-y made their first contribution in https://github.com/librosa/librosa/pull/1469
    • @Asmitha-K made their first contribution in https://github.com/librosa/librosa/pull/1473
    • @cr2007 made their first contribution in https://github.com/librosa/librosa/pull/1479
    • @LorenzNickel made their first contribution in https://github.com/librosa/librosa/pull/1487
    • @futurulus made their first contribution in https://github.com/librosa/librosa/pull/1504
    • @Xiao-Ming made their first contribution in https://github.com/librosa/librosa/pull/1511

    Full Changelog: https://github.com/librosa/librosa/compare/0.9.1...0.9.2

    Source code(tar.gz)
    Source code(zip)
  • 0.9.1(Feb 15, 2022)

    This minor release restores API compatibility for functions with positional arguments.

    See https://librosa.org/doc/latest/changelog.html for details.

    Source code(tar.gz)
    Source code(zip)
  • 0.9.0(Feb 7, 2022)

    This release introduces multichannel support and substantial number of bug fixes and enhancements.

    See https://librosa.org/doc/main/changelog.html#v0-9-0 for a full list of changes.

    Source code(tar.gz)
    Source code(zip)
  • 0.9.0rc0(Jan 31, 2022)

  • 0.8.1(May 26, 2021)

    This is primarily a bug-fix and maintenance release.

    New features include interactive waveform visualization, signal de-emphasis effect, and expanded resampling modes.

    A full list of changes can be found at https://librosa.org/doc/main/changelog.html#v0-8-1

    Source code(tar.gz)
    Source code(zip)
  • 0.8.1rc2(May 25, 2021)

  • 0.8.1rc1(May 23, 2021)

    First release candidate for 0.8.1.

    This is primarily a bug-fix and maintenance release. A full list of changes can be found at https://librosa.org/doc/main/changelog.html#v0-8-1

    Source code(tar.gz)
    Source code(zip)
  • 0.8.0(Jul 22, 2020)

    First release of the 0.8 series.

    Major changes include:

    • Removed support for Python 3.5 and earlier.
    • Added pitch tracking (yin and pyin)
    • Variable-Q transform
    • Hindustani and Carnatic notation support
    • Expanded collection of example tracks
    • Numerous speedups and bugfixes
    Source code(tar.gz)
    Source code(zip)
  • 0.7.2(Jan 13, 2020)

    This is primarily a bug-fix release, and most likely the last release in the 0.7 series.

    It includes fixes for errors in dynamic time warping (DTW) and RMS energy calculation, and several corrections to the documentation.

    Inverse-liftering is now supported in MFCC inversion, and an implementation of mu-law companding has been added.

    Please refer to the documentation for a full list of changes.

    Source code(tar.gz)
    Source code(zip)
  • 0.7.1(Oct 9, 2019)

    This minor revision includes mainly bug fixes, but there are a few new features as well:

    • Griffin-Lim for constant-Q spectra
    • Multi-dimensional in-place framing
    • Enhanced compatibility with HTK for MFCC generation
    • Time-frequency reassigned spectrograms

    Please refer to the documentation for a full list of changes.

    Source code(tar.gz)
    Source code(zip)
  • 0.7.0(Jul 8, 2019)

    First release of the 0.7 series.

    Major changes include streaming mode, feature inversion, faster decoding, more efficient spectral transformations, and numerous API enhancements.

    Source code(tar.gz)
    Source code(zip)
  • 0.7.0rc1(Jul 1, 2019)

    First release candidate of the 0.7 series.

    Major changes include streaming mode, faster decoding, more efficient spectral transformations, and numerous API enhancements.

    Source code(tar.gz)
    Source code(zip)
  • 0.6.3(Feb 13, 2019)

  • 0.6.2(Aug 9, 2018)

  • 0.6.1(May 24, 2018)

    0.6.1 final release. This contains no substantial changes from 0.6.1rc0.

    The major changes from 0.6.0 include:

    • new module librosa.sequence for Viterbi decoding
    • Per-channel energy normalization (librosa.pcen())

    As well as numerous bug-fixes and acceleration enhancements.

    Source code(tar.gz)
    Source code(zip)
  • 0.6.1rc0(May 22, 2018)

    First release candidate for 0.6.1.

    This is primarily a bugfix release, though two new features have been added: per-channel energy normalization (pcen) and Viterbi decoding (librosa.sequence module).

    Source code(tar.gz)
    Source code(zip)
  • 0.6.0(Feb 17, 2018)

  • 0.6.0rc1(Feb 13, 2018)

  • 0.6.0rc0(Feb 10, 2018)

    First release candidate for 0.6.

    This is a major revision, and contains numerous bugfixes and some small API changes that break backward compatibility with the 0.5 series. A full changelog is provided in the documentation.

    Source code(tar.gz)
    Source code(zip)
  • 0.5.1(May 8, 2017)

  • 0.5.0rc0(Feb 11, 2017)

  • 0.4.3rc0(May 15, 2016)

  • 0.4.2(Feb 20, 2016)

  • 0.4.1(Oct 17, 2015)

    This minor revision expands the rhythm analysis functionality, and fixes several small bugs.

    It is also the first release to officially support Python 3.5.

    For a complete list of changes, refer to the CHANGELOG.

    Source code(tar.gz)
    Source code(zip)
  • 0.4.1rc0(Oct 14, 2015)

  • 0.4.0rc2(May 23, 2015)

  • 0.4.0rc1(Mar 4, 2015)

    There are still a few issues to clean up with the 0.4 milestone, but these mainly relate to testing.

    This rc should be essentially feature complete.

    Source code(tar.gz)
    Source code(zip)
Owner
librosa
Python tools for music and audio analysis
librosa
a library for audio and music analysis

aubio aubio is a library to label music and sounds. It listens to audio signals and attempts to detect events. For instance, when a drum is hit, at wh

aubio 2.8k Sep 26, 2022
❤️ Hi There Im Cozmo Music Bot A next gen powerful telegram group Music bot for get your Songs and music @Venuja_Sadew

?? Cozmo MUSIC ?? Cozmo Music is a Music powerfull bot for playing music on telegram voice chat groups. Requirements FFmpeg NodeJS nodesource.com Pyth

Venuja Sadew 3 Jan 8, 2022
NovaMusic is a music sharing robot. Users can get music and music lyrics using inline queries.

A music sharing telegram robot using Redis database and Telebot python library using Redis database.

Hesam Norin 7 Sep 22, 2022
Okaeri-Music is a telegram music bot project, allow you to play music on voice chat group telegram.

Okaeri-Music is a telegram bot project that's allow you to play music on telegram voice chat group

Wahyusaputra 1 Dec 22, 2021
Okaeri-Music is a telegram music bot project, allow you to play music on voice chat group telegram.

??️ PROJECT MUSIC,THIS IS MAINTAINED Okaeri-Music is a telegram bot project that's allow you to play music on telegram voice chat group Features ?? Th

Okaeri-Project 2 Dec 23, 2021
Marsyas - Music Analysis, Retrieval and Synthesis for Audio Signals

Welcome to MARSYAS. MARSYAS is a software framework for rapid prototyping of audio applications, with flexibility and extensibility as primary concer

Marsyas Developers Group 360 Sep 26, 2022
cross-library (GStreamer + Core Audio + MAD + FFmpeg) audio decoding for Python

audioread Decode audio files using whichever backend is available. The library currently supports: Gstreamer via PyGObject. Core Audio on Mac OS X via

beetbox 410 Oct 1, 2022
cross-library (GStreamer + Core Audio + MAD + FFmpeg) audio decoding for Python

audioread Decode audio files using whichever backend is available. The library currently supports: Gstreamer via PyGObject. Core Audio on Mac OS X via

beetbox 359 Feb 15, 2021
Audio augmentations library for PyTorch for audio in the time-domain

Audio augmentations library for PyTorch for audio in the time-domain, with support for stochastic data augmentations as used often in self-supervised / contrastive learning.

Janne 158 Sep 29, 2022
Python audio and music signal processing library

madmom Madmom is an audio signal processing library written in Python with a strong focus on music information retrieval (MIR) tasks. The library is i

Institute of Computational Perception 965 Sep 26, 2022
Music player and music library manager for Linux, Windows, and macOS

Ex Falso / Quod Libet - A Music Library / Editor / Player Quod Libet is a music management program. It provides several different ways to view your au

Quod Libet 1.2k Sep 28, 2022
convert-to-opus-cli is a Python CLI program for converting audio files to opus audio format.

convert-to-opus-cli convert-to-opus-cli is a Python CLI program for converting audio files to opus audio format. Installation Must have installed ffmp

null 4 Aug 5, 2022
Audio spatialization over WebRTC and JACK Audio Connection Kit

Audio spatialization over WebRTC Spatify provides a framework for building multichannel installations using WebRTC.

Bruno Gola 34 Jun 29, 2022
praudio provides audio preprocessing framework for Deep Learning audio applications

praudio provides objects and a script for performing complex preprocessing operations on entire audio datasets with one command.

Valerio Velardo 102 Sep 14, 2022
Python Audio Analysis Library: Feature Extraction, Classification, Segmentation and Applications

A Python library for audio feature extraction, classification, segmentation and applications This doc contains general info. Click here for the comple

Theodoros Giannakopoulos 5k Sep 26, 2022
Python Audio Analysis Library: Feature Extraction, Classification, Segmentation and Applications

A Python library for audio feature extraction, classification, segmentation and applications This doc contains general info. Click here for the comple

Theodoros Giannakopoulos 3.8k Feb 17, 2021
A small project where I identify notes and key harmonies in a piece of music and use them further to recreate and generate the same piece of music through Python

A small project where I identify notes and key harmonies in a piece of music and use them further to recreate and generate the same piece of music through Python

null 4 Mar 29, 2022
We built this fully functioning Music player in Python. The music player allows you to play/pause and switch to different songs easily.

We built this fully functioning Music player in Python. The music player allows you to play/pause and switch to different songs easily.

null 1 Nov 19, 2021
Just-Music - Spotify API Driven Music Web app, that allows to listen and control and share songs

Just Music... Just Music Is A Web APP That Allows Users To Play Song Using Spoti

Ayush Mishra 3 May 1, 2022