# Every musicinformationretrieval.com notebook link builds from a second repository > An instructional course on music information retrieval, built as a Jupyter Book from numbered notebooks and deployed to a custom domain, with every lesson runnable in a hosted notebook service. Two structural details matter more than the curriculum. Every link in the table of contents points at a Binder environment built from a personal account rather than the organisation that hosts the files, and the repository's only release tag is twelve years old while the branch is still being pushed to. **musicinformationretrieval/musicinformationretrieval.com** — Instructional notebooks on music information retrieval. - Repository: https://github.com/musicinformationretrieval/musicinformationretrieval.com - Website: http://musicinformationretrieval.com - Stars: 1,280 · Forks: 413 - Language: Jupyter Notebook - License: MIT - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/musicinformationretrieval-musicinformationretrieval-com ## Every lesson link builds from a personal account, not the organisation hosting them The table of contents is a list of hosted-notebook links, one per lesson, and every single one of them names a different repository. The path in each link is the same account, a personal one, and the reference is to that account's HEAD rather than to a branch or a tag. Meanwhile the files themselves live under an organisation account, and the same author's name appears in the packaging metadata. So the repository you are reading is not the repository the site links out to. Clicking a lesson does not read the notebooks in this tree; it asks a hosted notebook service to build an environment from the other one. For a reader that is invisible, and for anyone who forks the project it is the single most expensive thing to change, because it touches every link in the course. ## The only release tag is twelve years old and still says 0.1.0 There is one release in the history, tagged version 0.1.0 in the middle of 2014. The packaging metadata at the root declares the same 0.1.0. Nothing has been re-tagged in the twelve years since, even though the default branch received a push in May of this year and the site itself is the product. So the version number is not a useful signal for anything: it has never moved, so it tells you neither how current the code is nor which state you have. There is no changelog in the tree either. What there is instead is a content structure that makes the current state obvious at a glance, since the numbered content directories are the curriculum and the last push date is the only recency signal in the repository. ## The default branch is the pages branch The branch this repository serves by default is the one hosting the deployed site. That is a choice with consequences for readers and for tooling. For a reader, cloning the repository without specifying a branch gets the built site rather than a source layout you can reason about, because the sources are under a content directory inside a directory that also holds the book configuration. For tooling, the branch names in the lesson links cannot refer to this repository at all, which is consistent with them pointing at the other account. The site has a custom domain recorded in a domain file at the root and a Python version file for the deployment platform, both of which are the fingerprints of a static site built by a hosting service rather than by a continuous integration pipeline that publishes from a main branch. ## Exercise notebooks and the drum-transcription notebook are excluded from the test run The build file runs two separate test invocations and they have different rules. The first runs the Python tests with every notebook ignored. The second executes notebooks as tests, with Python files ignored and three glob patterns excluded on top: anything matching exercise, and anything matching the drum-transcription library. ```make venv/bin/pytest --nbmake -n=auto --ignore-glob='*.py' --ignore-glob='*exercise*.ipynb' --ignore-glob='*adtlib*.ipynb' --reruns 3 --reruns-delay 5 mirdotcom ``` Both run in parallel with three retries and a five-second delay between them, which points to notebook execution being expected to be flaky. The exclusions are reasonable in principle, since an exercise is meant to fail and the drum transcription notebook pulls an external dependency. The consequence is worth stating plainly: a green run does not mean every lesson in the course executes, and the two categories left out are the ones a reader is most likely to copy and run for the first time. ## The test target is not declared phony, so a file named test would shadow it The build file declares four targets as phony: the run target, the install target, the build target and the fix target. The test target is not among them. In make, a target whose name matches an existing file is considered already up to date, and its recipe does not run. There is no file named test in the tree today, so the suite runs as intended, and the omission is the kind of thing that breaks silently the day someone creates a directory or a script with that name. It is a small thing and it sits next to a more visible one: the run and install targets both depend on a marker inside the virtual environment directory, and that marker is created by touching an empty file rather than by checking that the notebook server is really installed. So a half-finished install looks complete to make. ## The packaging metadata is empty where it matters The setup file is five statements long. It names the project, gives a version, gives the site URL, names an author, and lists one package to include. Then two empty values: an empty description and an empty classifier list. So anything that reads the packaging metadata from a package index rather than from this repository will find a project with no description and no declared Python versions. It is a small file for a project that is really a website rather than a library, and the editable install the build file performs exists to put one directory on the import path rather than to publish anything. The empty fields are consistent with that intent, but they are also the fields a consumer would look at first. ## One exact-pinned lockfile holds the learning stack and the documentation toolchain The dependency file is a compiled lock, generated by a compile tool, with an exact version on every line and a comment above each explaining which package pulled it in. It was generated against one Python minor version, and the formatting target in the fix command is pinned to the same minor. The list is long enough to be worth characterising by what is in it. You will find the audio and machine learning stack the course actually needs: an audio library, an evaluation library for audio, a rhythm transcription library, and a deep learning framework. You will also find the entire documentation stack, because the site is built from the same notebooks: a book builder, a Markdown notebook parser, a documentation theme, a notebook conversion library, and a notebook server. One environment for both jobs is a reasonable choice for teaching material, and it means the build environment is heavy. ## A macOS desktop artefact sits in the root of the repository Two small things in the tree are worth noting because they say how the project is maintained. The first is a macOS desktop metadata file committed at the top level, which is a leftover from a machine where folder view settings were being saved into the working directory. The second is the presence of a notebook template file at the root, which is how a Jupyter Book keeps the top-level page consistent while generating chapter navigation. Neither matters technically. Together they are a decent description of the project: a teaching site assembled from notebooks on a personal machine, published under an organisation account, with the automation kept to a makefile, a compile tool and two test invocations. ## Conclusion musicinformationretrieval.com is a good free curriculum for someone starting from audio fundamentals and working toward beat tracking, drum transcription and genre recognition, and the notebooks are genuinely executable rather than prose with code in it. Three things to know. If you plan to fork it, the lesson links point at another account, so your fork will keep building the original unless you rewrite every one of them. The environment is one exact-pinned lockfile that holds both the machine learning stack and the documentation toolchain, so expect a heavy install. And the exercise notebooks and the drum-transcription notebook are deliberately excluded from the test run, so passing the suite does not mean every lesson has been checked. ## FAQ ### What is musicinformationretrieval.com? An open-source course on music information retrieval, written as Jupyter notebooks and built into a book, covering audio fundamentals, musical representations, feature extraction, rhythm and beat tracking, and machine learning tasks such as genre recognition and instrument classification. ### Do the notebooks on musicinformationretrieval.com need anything installed locally? Not to read them. Every lesson link opens in a hosted notebook service that builds the environment for you. To work on the course locally you would use the build file's run target, which creates a virtual environment from the pinned dependency file and starts a notebook server. ### Are all the notebooks on the MIR course tested? No. The test run executes notebooks as tests but excludes every exercise notebook and every notebook that uses the drum-transcription library, on top of ignoring Python files. Both suites run in parallel with three retries and a five-second delay between them. ### Which branch does musicinformationretrieval.com serve by default? The pages branch, which is the one hosting the deployed site rather than a separate source branch. The lesson links do not point at this repository at all; they point at a hosted notebook service building from a different account. ### What are the external tools the MIR course relies on? The dependency lock pins the audio and machine learning libraries the notebooks use, including an audio library, an audio evaluation library, a rhythm transcription library and a deep learning framework, plus external audio tools covered by its own lesson. The pinned set was generated against Python 3.10. ## Sources - [License: MIT](https://github.com/musicinformationretrieval/musicinformationretrieval.com/blob/gh-pages/LICENSE) - [musicinformationretrieval/musicinformationretrieval.com on GitHub](https://github.com/musicinformationretrieval/musicinformationretrieval.com) - [Project website](http://musicinformationretrieval.com) - [README](https://github.com/musicinformationretrieval/musicinformationretrieval.com/blob/gh-pages/README.md) - [Releases](https://github.com/musicinformationretrieval/musicinformationretrieval.com/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/musicinformationretrieval-musicinformationretrieval-com