Managing MiniDisc Devices From the Command Line

february 25, 2022

MiniDiscs have long been one of my favorite music formats since I first got a recorder two years ago:

October 29, 2020: “hello minidisc :)”

And just a few days ago I finally got a NetMD recorder:

February 23, 2022: “New Gadgets: Thumby (Tiny Game Console) & the Sony MZ-N505 (MiniDisc Recorder/Player)”

So I've been working on getting a CLI NetMD setup going, as all the existing options are either electron-based (bad), or google chrome only (worse). Most of my other workflow is on the command line, if I can avoid it I'm not opening up a GUI or Web app to do just one thing. Particularly since I rerecord various discs every week or more, I wanted something that was convenient to use and was set it and forget it. platinum-md requires me to slowly navigate to the folder holding the song I want, select it to transfer, wait, then slowly navigate to the next folder and so on which is no fun. Also my six year old laptop fans rev up full speed the instant I opened it so that doesn't make it easy to forget it either.

Luckily all the web apps that I know of that actually do something useful (especially if it involves interfacing with USB or other hardware) simply use base CLI tools or js/webasm ports of those tools in their backend. All the web-based fusee launchers use a port of the CLI fusee-launcher in the backend. All of those free file converter sites just use ffmpeg in their backend. WebMD and platinum-md are (luckily) no different. Unfortunately the CLI tools in their backends are a bit finicky and undocumented, but there's workarounds.

netmd

The quintessential program for accessing NetMD devices is linux-minidisc. All other NetMD implementations that I know of are derived from it.

Unfortunately, the original linux-minidisc really leaves plain NetMD by the wayside and instead focuses on HiMD support, which seems to me to be a largely wasted effort since you have to be a millionaire in order to afford a working HiMD player these days.

Instead I have my own fork that integrates improvements from a bunch of linux-minidisc forks

The compilation instructions as given in the README are simple enough:

$ qmake CONFIG+=without_gui
$ make

You need qmake because there's a HiMD Qt app, even though we're disabling that anyways.

However, there are a few limitations to netmdcli, the primary utility in linux-minidisc. Namely:

The documentation is very poor
You can't upload more than one file at a time
You have to manually convert files to ATRAC when uploading in LP2 or LP4
You can't upload arbitrary formats without manually converting them to WAV first.

Let's address these problems one-by-one:

a crash course for netmdcli

The CLI documentation for netmdcli is very poor. I'm working on writing a real man page for it and cleaning up its netmdcli help text, but until that patch gets applied here's a crash course in the most useful commands:

netmdcli help

View a rather incomplete list of subcommands.

netmdcli

Did you know that running the command with no arguments will give you the track listing of the current MD? Well I sure as hell didn't, I only found out because I happened to notice it in the source code.

netmdcli status

Displays the raw disc title (including groups), the sanitized disc title, and info about the currently playing track.

netmdcli move

Move a track to a different position on the disc. Note that tracks in netmdcli are zero-indexed, which is off by one from the track numbers on the player itself. Use the netmdcli command to get the shifted track numbers.

netmdcli delete

Delete the track at target. Same caveats as netmdcli move.

netmdcli rename

Rename the track at target. Same caveats as netmdcli move.

netmdcli capacity

Display the remaining SP capacity on the disc. Multiply by 2 if you're recording in LP2 mode and multiply by 4 for LP4.

netmdcli erase force

Erase the disc. This has a tendency to make any later netmdcli commands mess up until you eject the disc and reinsert it.

netmdcli send </li> </ul> See <q>uploading tracks</q> below. <ul> <li>netmdcli settitle <new title></li> <li>netmdcli <groupmove|deletegroup|group|retitle></li> </ul> See <q>customizing groups</q> below. <h3 id="uploading-tracks">uploading tracks</h3> Note: in Sony-speak, <q>uploading</q> means transferring files from the MiniDisc to the computer; <q>downloading</q> means transferring files from the computer to the MiniDisc. However <q>uploading</q> is only possible on HiMD devices, and the terminology is confusing and backwards to me. So keep in mind that when I say <q>uploading</q> throughout this article, other people may call the same thing <q>downloading</q> (usually only when discussing HiMD-compatible softwaer). With that out of the way, let's get into uploading to MiniDisc. Uploading tracks over NetMD using solely netmdcli is very finicky and requires a lot of manual format munging to work properly. If you ever want to record in anything other than SP mode, the first thing you need to do is set up <code>atracdenc</code> <a href="https://github.com/dcherednik/atracdenc">an experimental FOSS codec fr ATRAC1 and ATRAC3</a> Just like with the original linux-minidisc, the focus of atracdenc seems to be ATRAC1 which is very strange since you cannot directly transfer ATRAC1 to MiniDisc and there are no other decoders out there. Not even Sony's first-party sonicstage software supports ATRAC1 natively, it directly sends out PCM audio which the MD recorder compresses itself, which is exactly what we'll be doing as well. What we'll be using atracdenc for is the <q>experimental</q> ATRAC3 support to support LP2 and LP4. Despite being experimental I haven't noticed any issues with it as long as you compile from the lastest master commit. You need a standard C++ compiler and CMake, plus libsndfile. All of those dependencies are super common so you shouldn't need to install anything on most *nix systems. The instructions require more commands but are basically the same for any CMake out-of-tree build: <pre> $ mkdir src/build $ cd src/build $ cmake ../ $ make </pre> Okay, once you have linux-minidisc and atracdenc—and additionally ffmpeg—set up, there's just a few simple steps to upload a single track to MD: Step 1) Convert the input file to signed 16-bit 44100 Hz PCM WAV Step 2) If uploading in SP mode skip to Step 6, otherwise continue with steps 3–4 Step 3) Use atracdenc to convert the raw WAV file to ATRAC3, using a bitrate of 128 for LP2 and 64 for LP4 Step 4) Wrap the ATRAC3 file in a WAV container, making sure to leave the audio stream iteself intact Step 6) Decide on the desired trackname that you want to store on the MD. Step 7) Use <code>netmdcli send <WAV file> <track name></code> to upload the track to MD Seems like a lot of work to do for every single track you want to upload? No worries! I put together a shell script to do all of it for you, for as many files as you can fit on a disc: <a href="files/netmd-upload.sh">files/netmd-upload.sh</a> The usage is rather simple: <pre> netmd-upload: Upload music files to a MiniDisc recorder via NetMD Usage: netmd-upload [-hp] [-e type] [-f format] <input files>... Flags: -e type ATRAC format to use, either "SP", "LP2", or "LP4". (default "SP") -f format Format string or file containing a format string to use for track names on the MiniDisc, in exiftool format: <https://exiftool.org/exiftool_pod.html#p-FMTFILE-or-STR--printFormat> (default "${title} - ${artist}") -h Display this help information. -p Preserve temporary intermediary files. input files One or more input files to convert to ATRAC and upload via NetMD. May be in any format supported by FFMPEG, although lossless formats are recommended. Use netmdcli(1) to manage the tracks once they are uploaded. </pre> Just plug in your NetMD recorder, select the recording mode with <code>-e</code>, then simply list all the files you want to upload. It'll automatically determine track names from the file metadata and deal with all the weird format conversions for you. There you go! An automated tool to upload tracks to MD, that's as convenient as (most) everything else is in netmdcli. <h3 id="customizing-groups">customizing groups</h3> For the uninitiated, <q>groups</q> are a way to organize any set of contiguous tracks on a disc into a group, such as an album for multi-album discs, or for each LP side if you're recording from vinyl. netmdcli has a number of operations for working with groups: groupmove, deletegroup, group, retitle, et al. I don't particularly like them though, they're simple enough to understand but not particularly user-friendly. I personally prefer to directly edit groups using <code>netmdcli settitle</code>. Yes, you heard that right: groups are stored in the disc title (for backwards compatibility reasons). The format is rather simple: <pre> 0;disc title//g1s-g1e;group 1 title//...//gNs-gNe;group N title// </pre> where <code>disc title</code> is aptly the title for the entire disc; <code>gNs</code> to <code>gNe</code> is the range of tracks in the group, inclusive; and <code>group N title</code> is obviously the title for that specific group. ** Be sure to note : the group's track numbers are one indexed, unlike the track numbers used by netmdcli itself. If you're using the track listing generated by running <code>netmdcli</code>, be sure to add one to every track number. You can verify that the group is set up correctly by running <code>netmdcli status</code>. The <q>Raw Title</q> should match the ** entire title that you set with settitle. If the title was truncated, that means you ran out of room on the MD. Either reduce the length of your group names or remove a track to make room. The <q>Disc Title</q> should be the title given between <code>0;</code> and the first <code>//</code>. The most common cause of issues for me is accidentally getting the track numbers wrong so a group has track numbers that don't exist on the disc. Also forgetting the leading <code>0;</code> or the trailing <code>//</code>. Also, if you don't want to use groups then there's no need to include the <code>0;title//</code>, instead just directly set the title string to what you want with no additional formatting. For an example, here's a real disc title with groups: <pre> 0;an Unkindness - Discography//1-12;10 Years//13-14;The Present//15-18;4 Songs//19-20;Low-Budget Randoms// </pre> <h2 id="real-time-dubbing">real-time dubbing</h2> I used real-time cassette-style dubbing for two years before getting a NetMD device, and I wouldn't particularly recommend it if you can avoid it. Especially since non-NetMD recorders don't seem to be much cheaper than NetMD recorders. It's very slow and if you regularly re-record MDs like I do it can be a massive time sink. I'll still do it occassionally to record from vinyl records or existing tapes, but I don't think I'll do it again for transcribing digital music. But dubbing is a lot simpler than NetMD: If your recorder has an optical line-in, and you have a computer or DAC that has optical line-out, then you're golden! Pick up a TOSLINK optical cable and Mini-TOSLINK adapters (they both should be cheap and readily available), and then it's just plug-and-play; audio out of your computer, audio into the MD recorder. Analog dubbing should be your last resort only if your equipment doesn't support anything else, as it'll produce the lowest quality recordings. It's the same as optical dubbing, but instead use a standard 3.5 mm patch cable. <h2 id="bonus-atrac-codec-comparisons">bonus: atrac codec comparisons</h2> For those curious, here's a sample of the various formats used by MiniDisc players for your listening comparison. I used a sample of Big Audio Dynamite's Rush, as it's notorious for compressing badly—in my experience at least. The high-tempo melody and complex multi-track backing is just a mess when it's highly-compressed. The ATRAC3 samples should be decodable by anything that uses libavcodec in its backend: VPC, MPV, mplayer, and most desktop music players should work. It most certainly won't work in your browser's built-in media player though. I'd include a raw ATRAC1 file in the samples but there seems to be no available codec for the AEA container format used by ATRAC1, so I compressed the source sample to ATRAC1 and then decoded it back to a common format. <a href="/files/atrac-sample/sample_cd-source.flac">Original 44,100 Hz 16-bit FLAC [818.5 KiB]</a> <a href="/files/atrac-sample/sample_128kbps.mp3">128 Kbps MP3 [111.6 KiB]</a> <a href="/files/atrac-sample/sample_64kbps.mp3">64 Kbps MP3 [60.4 KiB]</a> <a href="/files/atrac-sample/sample_sp-292kbps.flac">292 Kbps ATRAC1 (SP mode), decoded back to FLAC [819.6 KiB, Original ATRAC1 file 263.7 KiB]</a> <a href="/files/atrac-sample/sample_lp2-128kbps.at3">128 Kbps ATRAC3 (LP2 mode) [118.6 KiB]</a> <a href="/files/atrac-sample/sample_lp4-64kbps.at3">64 Kbps ATRAC3 (LP4 mode, but without joint stereo) [59.3 KiB]</a> The original is a CD rip, losslessly compressed to FLAC. The MP3s were compressed using Tenacity (which uses LAME in the backend) in <q>average bitrate</q> mode, with joint stereo enabled. The ATRAC samples were all compressed using the <code>atracdenc</code> experimental encoder. In my opinion the LP4 ATRAC3 is pretty bad, but far better than the 64 Kbps MP3; LP2 is comparible to but slightly worse than the 128 Kbps MP3; and SP is in the same range as 320 Kbps MP3 or >=128 Kbps VBR OPUS: almost-to-entirely indistinguisable from lossless audio. </article> <footer> <hr/> <a href="/gemlog/">↩ go back to index</a> <a href="gemini://nytpu.com/gemlog/2022-02-25.gmi">also available on gemini</a> <a href="mailto:alex@nytpu.com">contact via email: alex [at] nytpu.com</a> <a href="/about.html">or through anywhere else I'm at</a>  <a href="https://creativecommons.org/licenses/by-sa/4.0/">Copyright © 2022 nytpu - CC BY-SA 4.0</a> </footer> </body> </html>