FAQ

The pipeline only replaces the catalogue metadata it actively rewrites. Everything else stays untouched.

Replaced (the service writes these from scratch):

• Album title, album artist, artists per track
• Composer, conductor, ensemble, performer, soloist, arranger, lyricist
• Title, work, movement, movement number / total, grouping
• Genre, label, catalogue number
• Track number / total, disc number / total

Preserved (everything not in the replace list):

• Cover art — embedded artwork passes through unchanged
• MusicBrainz IDs — existing IDs are kept; missing ones get filled in (details in the dedicated MBID entry below)
• Year / release date
• Comments, lyrics, ratings, play counts, custom date-added timestamps
• Any other custom fields your player or tagger has written

The replace list is configurable per job — if you have a custom field or a strict policy you want me to override, mention it during the dry run and I'll add it to the list (or take it out).

Yes. If your files already have MBIDs (release, release-group, track, release-track), they're carried through unchanged. The pipeline runs in two passes:

1. First pass uses your existing MBIDs as-is — no re-identification, no overwrites. Whatever release you're already linked to in MusicBrainz stays linked.
2. Second pass fills in MBIDs only on tracks that don't have any yet (rips from tools that don't write MBIDs, or pre-MB-era files).

This keeps existing ripping-tool reports, AccurateRip verifications, and any external tool or service that links to your MBIDs working exactly as before — only the surrounding tags are normalised.

Anything non-audio that came with your rip passes through untouched. The pipeline only retags audio files (FLAC / M4A / OGG — M4A covers both AAC and ALAC); everything else in the album folder gets mirrored to the delivered tree exactly as you sent it.

So if your album folder contains:

• 12 FLAC tracks
• EAC log + AccurateRip verification
• Booklet scans (PDF or images)
• folder.jpg / cover.jpg
• .cue sheet, .m3u playlist

You'll get the same folder back with only the audio re-tagged. The EAC log, AccurateRip status, scans, cue sheet, playlist — all preserved. The audio's MusicBrainz IDs survive too, so existing ripping-tool reports still match.

Both convert to any supported format free of charge as part of the job. FLAC is the sensible default (lossless to lossless, no quality compromise), but if you want M4A (AAC or ALAC) or OGG output instead, just say so on the intake form or in the notes. Same workflow either way.

WAV — one input file per track (the standard layout from ripping). Lossless source, so output to FLAC or ALAC is bit-perfect; output to AAC or OGG is lossy by codec definition but the source itself stays clean. No cue sheet needed; track boundaries are already where they should be.

APE (Monkey's Audio) — needs a .cue sheet alongside the APE file(s) so the audio can be split into per-track output files. The typical APE layout is one big Album.ape plus an Album.cue that names each track and marks its start time. Most APE rips ship this way; if yours doesn't, send what you have and we'll see what's recoverable — but with the cue, the split is clean.

After the source is transcoded, the output files go through the same classical-aware tagging pipeline as any other input.

M4A is a container, not a codec. The same .m4a file can hold either:

• AAC — the lossy codec iTunes / Apple Music used by default for years. Ripped at ~256 kbps from iTunes Match / Apple Music downloads, transparent for most listeners.
• ALAC (Apple Lossless) — bit-perfect, same audio fidelity as FLAC, larger files. The format dbpoweramp and XLD produce when you tell them "Apple Lossless".

The tag pipeline treats both identically. iTunes-style atoms (©nam, ©ART, ©wrt, etc.) live in the same place in the container regardless of which codec sits in the audio track, so classical-aware tagging works for both AAC and ALAC without distinguishing between them. Same goes for embedded cover art.

Send whichever you have; the workflow is the same.

If your files have embedded artwork already, it's preserved through the scrub.

If they don't — and you'd like them to — I can add it as part of the job. Source can be anything you supply, or fetched from the MusicBrainz Cover Art Archive via beets when the release has it.

Two delivery options:

• cover.jpg in the album folder (preferred). Most players — Roon, Lyrion, Plex — read this automatically, and the file stays outside the audio container so it's easy to swap.
• Embedded in each track. Required for Apple Music / iTunes (those apps don't read folder-level covers).

For M4A tracks (AAC or ALAC — the cover-art atom is the same in both) I do both — folder file and embedded copy — since Apple needs the embed.

Tagged files come back in a folder tree built from the tags. Defaults:

• Classical: Composer / Genre / Performer / Album
• Jazz: Artist / Year - Album

See the home page for a real sample tree.

…or stop caring about folder structure entirely

You can use the open-source helper at codeberg.org/nadl40/links and the on-disk layout becomes mostly irrelevant. It builds a parallel symlink tree giving you any number of browse views (by composer, by artist, by genre, by catalogue ref) all pointing at the same underlying audio. None of the actual files move, and you can rebuild the tree any time with a different config.

For most players — Roon, Lyrion, Plex — browsing happens through tags anyway, not through file paths. Once your tags are clean, the on-disk folder structure is just where the audio lives. There's no need to browse it unless you prefer to.

The helper is MIT-licensed. I'll hand you a starter config mapped to your library; you run it on your machine.

Delivery is via Google Drive — I share a folder, you copy the files to your own machine. Three paths, depending on library size:

Small library (under ~100 CDs / 50 GB FLAC) — click the "Download" button in Google Drive's web UI. Drive packages the folder as a zip server-side and streams it. Quick and zero setup.

Larger libraries — Drive splits big folders into multi-part zips that fail intermittently on slow / interrupted connections. Use one of these instead:

• Google Drive for Desktop (free official client) — install, sign in, sync the shared folder to your local disk. Files arrive in their original folder layout, no zip, fully resumable across reboots. Best for non-CLI users.
• rclone — same CLI tool I use on my end. One-time rclone config against your Google account, then rclone copy gdrive:<shared-folder> ~/local. Resilient on flaky connections, easy to script.

The dashboard automatically suggests the right path based on your library size. Above ~100 CDs, the customer-facing instructions lead with Drive Desktop / rclone; below that, the browser zip path is fine and gets the prominent button.

A few practical notes:

• Google's daily download quota is around 750 GB per authenticated account, so a ~2,000-CD library may take two days. Drive Desktop and rclone both pause and resume cleanly.
• "Anyone with the link" anonymous downloads have aggressive throttling at >100 MB. If you're an audiophile who'd rather not log in, switch to the link as authenticated user — the quotas open up.

You get two checkpoints to bail out:

1. Free 10-CD dry run — before any payment. You pick 10 CDs, I tag them, you see the actual tag output in your player. If the result doesn't fit how you want your library to read, you walk away with nothing owed.

2. 15-second-per-track preview — after the deposit, before the balance. Once tagging is complete I deliver the whole library as short clips with full tags intact. You scan through every track in your player to verify the metadata's right and the audio matches. Reply with anything that looks off and I'll fix it before sending the final files. The balance is only due once you've reviewed.

Fixes at this stage are for factual errors — wrong composer, wrong performer credits, wrong work title, missing tags on a release MusicBrainz already carries. Stylistic preferences that conflict with how the service is documented (e.g. a different genre scheme, alternative composer name spellings), or albums that weren't in the original intake, are out of scope at this point — the dry run earlier is the right checkpoint for those.

Once you've paid the balance and the full library is delivered, that's the end of the loop — re-runs aren't part of the service. The two checkpoints above are where corrections happen.

On a single Linux machine I control. No cloud upload from my side during the job. The cloud share you opened (Google Drive / Dropbox / etc.) is the only point where the files exist outside your infrastructure or mine.

After delivery, the source copy on my machine is destroyed. The Google Drive folder I returned the tagged library in expires shortly after you've confirmed receipt — I revoke access and delete the folder.

The MusicBrainz contributions stay public, of course. That's the open-data part. But your files are gone.

No. Genre gets rewritten to the multi-level scheme described on the home page — Classical, Mozart, Symphonies style for classical, flat Jazz for jazz. Custom genre conventions don't survive the job.

If preserving your existing genres matters more than getting the curated tree, this isn't the service for you — and the dry run will surface that before you've committed anything.

Yes, when MusicBrainz has them. The default uses MusicBrainz's English title — the work's own title when it's already in English, and the English alias when MB lists the work primarily in another language (e.g., The Magic Flute in place of Die Zauberflöte). Choosing original language at intake flips that for foreign-language works — you'd get Die Zauberflöte, L'incoronazione di Poppea, etc. English-native works look the same either way. The choice applies to the whole library.

Tagged when MusicBrainz already has the box well-structured: release relationships in place, work / movement breakdowns and per-disc performer credits. The strength of the service is curating MB's existing data into clean tags. On a 100-disc box that's missing those relationships, building them by hand is days of MB editor work per release — that's outside scope.

Worked example: a release like Bach 333 — J.S. Bach The New Complete Edition sits squarely in the "well-documented" category and tags cleanly. A label retrospective newly added to MB with track titles only would not.

If you have a box you're unsure about, send the MB release URL during intake and I'll tell you up front whether it's in scope. If the release isn't on MB at all, that's an automatic out-of-scope for the box — the rest of your library is unaffected.

Tagging is the focus, so ripping isn't part of the standard service — physical handling, disc cleaning, AccurateRip verification and return shipping are a different workflow, and bundling them with tagging would dilute both. The default path is to use a third-party ripper as the first step, then send me the resulting files.

Suggested rippers (US-based, mail-in):

• DiscBurn (Minneapolis, MN) — primary recommendation. $1–2/CD depending on quality tier. Rips to FLAC (one of the three formats I support — see below) and delivers via a 30-day cloud link, which becomes the "send the library" step on the how-it-works page.
• Progressive Labs — backup. $1/CD, multiple US locations, FLAC supported. $0.25/CD surcharge for jewel-cased discs.

Canadian customers — special arrangement. No Canadian mail-in ripping service exists that I've found, and shipping discs across the US border means customs forms both ways plus round-trip postage in the CAD 30–60 range on top of per-CD pricing. So for Canadians I can take the ripping in-house as a separate arrangement — get in touch and we'll work out a per-CD rate. I rip with whipper, the Linux equivalent of EAC: AccurateRip-aware, bit-perfect, and it produces an EAC-style verification log alongside the audio files (FLAC, M4A or OGG).

Or rip yourself. dbpoweramp (Windows / Mac, paid) and EAC (Windows, free) are the standard tools.

A few things worth knowing whichever path you pick:

• Ask about rip verification. AccurateRip / EAC logs are the audible evidence that the rip is bit-perfect. DiscBurn doesn't publicly mention either — ask before shipping a large collection. (Whipper produces them automatically.)
• Don't pay rippers for tagging. Ask for files in FLAC, M4A (AAC or ALAC) or OGG (the formats I support) with default tags or none at all — I rewrite the catalogue metadata regardless, so paying twice would be wasted.