Automatic Ripping Machine: a headless pipeline for Blu-ray, DVD and CD ripping
Automatic Ripping Machine (ARM) Scripts
At a glance
- What is it?
- ARM watches your optical drives with udev, identifies each disc, rips it with MakeMKV or HandBrake, and drops the result into a Plex- or Emby-friendly folder name. Here is how the pieces fit together, what the Docker image assumes about your host, and where it stops being the right tool.
- Who is it for?
- ARM fits anyone running a headless Linux box or NAS with one or more optical drives who wants discs to rip themselves and land in a media library without manual naming. It is a poor fit if you want a desktop application, if you cannot give a container raw access to /dev/sr0, or if you object to sending disc fingerprints to OMDb and MusicBrainz.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 5 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 2, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What ARM automates, and the workflow it replaces
The manual version of this job is a loop: insert a disc, wait for the drive to spin up, open a ripping tool, guess whether the disc is a movie, a TV season or an audio CD, pick the right title, name the output folder, start a transcode, then repeat. Automatic Ripping Machine exists to delete that loop. The README describes the intended usage in three lines: insert disc, wait for disc to eject, repeat.
The project is aimed at people who run a server rather than a desktop. The README states it is "headless, designed to be run from a server," and that it can rip from multiple optical drives in parallel. That combination points at a specific user: someone with a rack or a NAS, a stack of discs to work through, and a media library that expects clean folder names. The Flask UI is there for inspection and for nudging jobs, not for driving the rip by hand.
How ARM decides what a disc is and what to do with it
The mechanism starts at the kernel level. Per the README, ARM detects insertion of a disc using udev, so the trigger is a device event rather than a polling loop or a cron job. Once a disc appears, ARM classifies it as audio, video or data, and the branch it takes determines everything downstream.
For video, the flow is the most involved. ARM retrieves a title from the disc or from the OMDb API, and uses that to name the output folder in the form "Movie Title (Year)" so that Plex or Emby can match it. OMDb is also what decides whether the disc is a Movie or a TV show. Ripping itself is done by MakeMKV or HandBrake, and the README notes ARM can rip all features or just the main feature. When the rip finishes, ARM ejects the disc and queues a HandBrake transcode. Those transcoding jobs are batched asynchronously from ripping, which is the design decision that matters most: a rip can start on drive two while drive one is still transcoding, and the two stages do not block each other.
Audio discs take a different path. The README says CDs are ripped with abcde, with disc data and album art pulled from MusicBrainz. Data discs, including Blu-ray, DVD, DVD-Audio and CD, are handled as an ISO backup rather than a transcode. Notifications go out through IFTTT, Pushbullet, Slack, Discord and other services, so the machine can tell you when it is done instead of you watching an LED.
Installing ARM with Docker and running a first rip
The README does not put install commands in the repository itself. It points to the project wiki, with separate pages for a normal installation and for Docker. The Dockerfile in the repository is the concrete artifact you can read: it is built on `automaticrippingmachine/arm-dependencies:1.8.0`, exposes port 8080, and creates `/home/arm` and `/home/arm/config` alongside mount points from `/mnt/dev/sr0` through `/mnt/dev/sr20`, each added to `/etc/fstab` with the options `defaults,users,utf8,ro`.
That layout tells you what the container expects from the host. The drive device has to be passed through, and the config directory has to be persistent if you want your settings to survive a container replacement. The Dockerfile's own `EXPOSE 8080` and its directory creation are the only concrete install facts the repository gives you; the wiki's Docker page is where the run command lives.
A compose file is the more common shape for this kind of service, and the wiki has a Docker page for it. The concerns that matter are the same three the Dockerfile encodes: the optical device, port 8080, and the `/home/arm/config` directory. After the container is up, the first real test is physical. Insert a disc, watch the UI for a job, and wait for the drive to eject on its own. If the disc ejects without a job appearing, the problem is almost always the device passthrough or the udev event not reaching the container, not the ripping tools.
Where ARM breaks down or is simply the wrong choice
The dependency on OMDb is the sharpest limitation, and the README states it plainly: video naming and the Movie-versus-TV decision both go through the OMDb API. That means an API key is part of setup, an internet connection is part of normal operation, and a disc that OMDb does not know will not get the folder name the library expects. The README does not document a fallback naming scheme for unidentified video discs.
Disc classification is the next weak point. ARM has to decide whether a disc is audio, video or data before it does anything useful, and the README does not describe what happens when that guess is wrong. A misclassified disc either gets an ISO backup you did not want or a rip you will delete. There is no documented override in the README for forcing a disc down a particular path.
The Dockerfile's mount table is a design assumption with consequences. It pre-creates paths for twenty-one drives, from `sr0` to `sr20`, and writes fstab entries for each. That is generous, and it is also a hint about the intended deployment: a machine with many drives, not a laptop with one USB Blu-ray burner. If you are ripping from an external USB drive that appears and disappears, the static device mapping is more friction than help.
Finally, ARM is a server tool. The README's requirements are a system capable of running Docker containers, one or more optical drives, and a lot of drive space, with the README suggesting a NAS for storage. There is no desktop application here, and no documented Windows or macOS native path in the README itself.
ARM against a manual MakeMKV and HandBrake workflow
The obvious alternative is not another product. It is doing the same two tools by hand: MakeMKV to pull the titles off the disc, HandBrake to transcode, and a file manager to rename the folder. That workflow uses the same underlying rippers ARM drives, so the output quality is a function of your settings either way.
The difference is entirely in the orchestration. Manual ripping gives you a decision point on every disc: which titles, which preset, what name. ARM removes those decision points by making them once, in configuration, and then applying them unattended. The cost is that ARM has to guess, and its guesses come from disc metadata and OMDb. A person looking at a disc case will beat OMDb on an obscure title every time. For a box of fifty mainstream movies, the automated guess is usually right and the time saved is real. For a shelf of foreign films, concert bootlegs or out-of-print TV, the manual path will produce a cleaner library with less cleanup afterward.
There is a middle position worth naming. ARM's transcoding stage is queued asynchronously from ripping, so you can let ARM handle detection, ripping and ejection while still reviewing the output before it reaches your library. That gets you the unattended drive handling without accepting every naming decision.
Maintenance, releases and the MIT licence
The repository is not archived, and the last push was on 2026-09-21. Releases are frequent and versioned in the 2.24.x line, with 2.24.3 published on 2026-08-01, 2.24.2 on 2026-07-26 and 2.24.1 on 2026-07-22. The README points to the wiki for both normal and Docker installation and for troubleshooting, and the repository carries a CHANGELOG.md, a CONTRIBUTING.md, a CODE_OF_CONDUCT.md and a SECURITY.md.
The practical upgrade cost is the container image and the config directory. Because the Dockerfile creates `/home/arm/config` separately from the application code, a container replacement should leave your settings in place as long as that path is a volume. What the README does not document is a rollback procedure or a migration step between minor versions, so the safe assumption is that you keep your config volume backed up before pulling a new image.
The licence is MIT, per the README and the LICENSE file, and the Dockerfile carries an `org.opencontainers.image.license=MIT` label. MIT is permissive, so redistribution and modification are broadly allowed with the licence text retained. That is a statement about the licence text, not legal advice about your situation; if you plan to ship ARM inside a product, read the LICENSE file and the licences of the tools it invokes, since MakeMKV, HandBrake and abcde are separate projects with their own terms.
Editorial conclusion
ARM fits anyone running a headless Linux box or NAS with one or more optical drives who wants discs to rip themselves and land in a media library without manual naming. It is a poor fit if you want a desktop application, if you cannot give a container raw access to /dev/sr0, or if you object to sending disc fingerprints to OMDb and MusicBrainz. Before committing, verify that your host exposes the optical device to the container, that your media share is mounted at the path ARM writes to, and that you have an OMDb API key, since the README says video naming depends on it.
Frequently asked questions
What is the Automatic Ripping Machine?
It is a headless service that watches for an inserted Blu-ray, DVD or CD, works out whether the disc is audio, video or data, and then rips it, ejects it and optionally queues a HandBrake transcode. The README describes the whole user workflow as insert disc, wait for eject, repeat.
How do I install the Automatic Ripping Machine with Docker?
The README does not include install commands and instead points to the project wiki, which has a dedicated Docker page. The repository's Dockerfile builds on automaticrippingmachine/arm-dependencies:1.8.0, exposes port 8080 and expects optical devices under /mnt/dev/sr0 through /mnt/dev/sr20.
How do I set up the Automatic Ripping Machine?
Setup means giving the container access to your optical drive and a persistent config directory, then letting udev events trigger jobs. The README states video naming and the Movie versus TV decision rely on the OMDb API, so an OMDb key is part of getting video rips named correctly.
How do I update the Automatic Ripping Machine?
The README does not document an update procedure. Releases are published on the repository's releases page, with 2.24.3 dated 2026-08-01, so updating means pulling a newer image or source revision. Because the Dockerfile keeps configuration in /home/arm/config, that path is the one to preserve across an update.
How do I use the Automatic Ripping Machine?
Insert a disc and wait. The README lists the usage as insert disc, wait for disc to eject, repeat. The Flask UI, served on port 8080 in the Docker image, is there to interact with ripping jobs, view logs and update jobs.
Can I use the Automatic Ripping Machine on my TrueNAS?
The README does not mention TrueNAS. It states the requirements as a system capable of running Docker containers, one or more optical drives, and plenty of drive space, and it directs Docker users to the wiki's Docker page. Whether a given NAS passes optical devices through to a container is a question about that NAS, not about ARM.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/automatic-ripping-machine-automatic-ripping-machine)