The Media Sucker

This program watches your CD/DVD drive. When you put a CD or DVD in, it will suck the content off, eject the drive, and then re-encode the content to a compressed format.

What It Supports

At the time I'm writing this README, it will:

• Rip audio CDs, look them up in cddb, encode them to VBR MP3, then tag them. A rewrite broke this; I plan to fix it soon.
• Rip video DVDs, transcode them to mkv

Requirements

• HandBrakeCLI
• cdparanoia
• cd-discid

How To Run This

You need a place to store your stuff. Mine is /srv/ext/incoming.

docker run \
    --name=sucker \
    -d --restart=always \
    -p 8080:8080 \
    --device /dev/sr0 \
    -v /srv/ext/incoming:/incoming \
    registry.gitlab.com/dartcatcher/media-sucker/media-sucker

I can't get it to work with docker swarm. Presumably some magic is happening with --device. It probably has something to do with selinux.

Stick a video DVD or audio CD in, and the drive should spin up for a while, then spit your media back out. Then, eventually, you'll have a new .mkv file (for video) or a new directory of .mp3 files (for audio).

You can watch what it's doing at http://localhost:8080/

A note on filenames and tags

This program does the absolute minimum to try and tag your media properly.

For DVDs, that means reading the "title" stored on the DVD, which I've seen vary from very helpful (eg. "Barbie A Fashion Fairytale") to ridiculously unhelpful (eg. "FBWTF2"). But at least it's usually unique for each DVD and at least somewhat related to the DVD contents.

For CDs, the situation is even worse. Audio CDs do not store any metadata, so CDDB takes the length of every track in seconds and tries to match that against something a user has uploaded in the past. This is wrong a whole lot of the time.

If CDDB can't find a match for an audio CD, this program will append the datestamp of the rip to the album name, in the hopes that you can remember about what time you put each CD in the drive. So for stuff like multi-CD audiobooks, that's pretty helpful.

But the end result in almost every case is that you're going to have to manually edit the metadata.

Answers

I'm skipping the part where I make up questions I think people might have.

Why I Wrote This

The automatic-ripping-machine looks really badass. But after multiple attempts across multiple months to get it running, I decided it would probably be faster just to write my own.

This isn't as cool as the aumomatic-ripping-machine. But, at least for me, it's a lot more functional, in that it actually does something.

Why You Should Run This

The only reason I can think of that anybody would want to use this is if they, like me, are too dumb to get the automatic-ripping-machine to work.

What Kind Of Hardware I Use

I run it on a Raspberry Pi 4, with a Samsung DVD drive from the stone age.

Parting note

As of 2022-08-22, large sections of this code were written under COVID brain-fog. This means it's going to look a lot like a 13-year-old wrote it.

I hope one day to clean it up a bit, but it's working fairly well, despite the mess. Please don't judge me for the organization of things. Judge bizarro universe Neale instead.