quebin31/muso

muso: music sorter

About

muso is a CLI tool that helps you to keep your music folder sorted. It's designed to be simple and fast, but also powerful and fully automated. Currently muso supports MP3, FLAC, OGG, M4A and M4P.

Building

To build muso yourself you need at least Rust 1.41. If you aren't going to install it using a package manager you should build muso with feature standalone activated, for example:

cargo build --features standalone --release

The standalone feature include contents of service and config in binary, so muso can create these files by itself.

Installing

To install from source using cargo (installed bin is in $HOME/.cargo/bin) you can do the following:

cargo install --path . --features standalone

Package is also available on the AUR for Arch Linux, just install it using your preferred method, for example:

yay -S muso

Concepts

Format string

muso is all about renaming and moving files around, but how it'll decide where the new file will reside, or which is going to be its name? Fortunately you can tell muso how to rename your files with a format string. This string will build the new name (path) using one or more of the following placeholders:

• {artist}: Artist name (Album Artist from tags is preferred, then Artist).
• {album}: Album name.
• {disc}: Disc number.
• {track}: Track number.
• {title}: Song title.
• {ext}: File extension (e.g. mp3, flac)

As an example, the default format that muso will use is the following.

"{artist}/{album}/{track} - {title}.{ext}"

The {disc} and {track} placeholders have the option to fill with leading zeros, the syntax is {disc:n} or {track:n} where n is the length that has to be achieved adding leading zeros. For example, using {disc:2} will produce the following transformations:

• 2 will become 02
• 10 will become 10

Finally, all of these placeholders (except {ext}) support an optional flag (activated by adding a ? before the }, e.g. {artist?}, {disc:2?}). Renaming a file that doesn't have an specific tag doesn't fail but leaves empty that placeholder in the string, however note that there are some rules:

• Directory components cannot be optional (e.g. this is invalid {artist}/{album?}/{title}.{ext})
• File name component must have one required placeholder, apart from {ext} (e.g. this is invalid {artist}/{title?}.{ext})

Note: These rules may be different in the future if I find a better way to fill these "unknowns" (possibly using ? for digits and Unknown for strings, or adding the option to provide a custom value).

A format string can be specified for oneshot mode using the -f/--format option, or providing it in for each library in the config file.

Libraries

We recently talked about libraries, these objects are used in the config file to provide muso settings while it's running in watcher mode. For example, the default library provided in the default config file is described as follows.

[libraries.default]
# Specified format that will be used for this library
format = '{artist}/{album}/{track} - {title}.{ext}'
# Folders that compose this library
folders = ['$HOME/Music']
# If enabled, the rename will be compatible with exFAT
exfat-compat = true

They are used to provide different options, to different folders.

Config file

muso will search for a config file in the following directories in order:

• $XDG_CONFIG_DIR/muso/config.toml
• $HOME/.config/muso/config.toml

It's also possible to indicate a custom path for config file with the -c/--config option. Config file is primary used when running in watcher mode, but it's also able to provide a default format string for certain folders while running in oneshot mode. For example, in the default config file the default library specifies a format and a list of folders, if you would run muso on $HOME/Music without specifying a format, it'll try to grab it from the config file, if there isn't one that correspond to the folder it'll fallback to the default.

Usage

muso can be used in two modes: oneshot and watcher. Both of them have similar functionalities, but as the naming suggest they perform it differently. Below we have the output of muso --help, which explains each option or flag available

USAGE:
    muso [OPTIONS] <SUBCOMMAND>

FLAGS:
    -h, --help       Prints help information
    -V, --version    Prints version information

OPTIONS:
    -c, --config <config>    Path to custom config file

SUBCOMMANDS:
    copy-service    Copy service file to systemd user config dir
    help            Prints this message or the help of the given subcommand(s)
    sort            Sort a music directory
    watch           Watch libraries and sort added files

Oneshot

By the default, muso will run on the current working dir, but you can provide your own path as a free argument. Config file is optional in this mode.

Watcher

In this mode config file is required, and as it's described in section [watch] of the default config file, the watcher can be configured.

[watch]
every = 1 # second(s)
# Specifies which libraries will be seen by muso
libraries = [ 'default' ]

Systemd service

It's recommended to invoke the watcher mode using the provided service file for systemd, this way you can run muso automatically on boot. Service file should be run on user level (systemctl --user). The easiest way to copy the service file is running muso with copy-service subcommand.

License

GNU General Public License v3.0

See LICENSE to see the full text.

muso's Issues

MP3 containing synced lyrics produces "Parsing: invalid SYLT timestamp format"

Describe the bug
If an MP3 contains embedded lyrics (synced lyrics) via the SYLT tag, muso fails sorting them, no matter if the embedded lyrcis are conforming the ID3v2.3/4 or not.

To Reproduce
Steps to reproduce the behavior:

1. Add synced lyrics to the MP3 file (e.g. via SYLT Editor)
2. Drop it to (one of) the watching directory of muso
3. muso throws the error Parsing: invalid SYLT timestamp format

Expected behavior
The SYLT tag is unimportant for the sorting of the files. No matter if the content of the tag is valid and/or parseable, muso should not refuse sorting the file.

Desktop (please complete the following information):

• OS: Arch Linux

Additional context
The used version of muso is 1.5.0.

Allow using DISCNUMBER as format argument.

Would be useful to name tracks of multi-disc digital releases:

{discnumber}.{track} {title}.{format}

---

Relevant wiki page:

https://wiki.hydrogenaud.io/index.php?title=Tag_Mapping#Counts_.26_Indexes

Add options to make tags optional

When a file has e.g. have a value for the Disc-Tag and I wan't to include this in the sorting. (for example with the followinf format-string: {artist}/{album}/{disc}{track} - {title}.{ext}).
When there are now files without that tag, these files will not get sorted.

Therefor I propose a feature: some kind of optional-marker which can be added to tags.

Allow leading zeros for track and disc

Is your feature request related to a problem? Please describe.
If you use the {discnumber}{disc} or {track} placeholder, the filename only contains the numbers without a leading zero.

Describe the solution you'd like
It would be amazing to have the ability to set an option allow using leading zeros.

Thank you very much for this cool piece of software!

Seperate output directory

It would be practical to be able to specify a output directory, seperate from the input dir.

error[E0308]: mismatched types

error[E0308]: mismatched types
  --> /wrkdirs/usr/ports/audio/muso/work/muso-2.0.0/cargo-crates/lexical-core-0.7.4/src/atof/algorithm/bhcomp.rs:62:24
   |
62 |     let bytes = bits / Limb::BITS;
   |                        ^^^^^^^^^^ expected `usize`, found `u32`

error[E0277]: cannot divide `usize` by `u32`
  --> /wrkdirs/usr/ports/audio/muso/work/muso-2.0.0/cargo-crates/lexical-core-0.7.4/src/atof/algorithm/bhcomp.rs:62:22
   |
62 |     let bytes = bits / Limb::BITS;
   |                      ^ no implementation for `usize / u32`
   |
   = help: the trait `Div<u32>` is not implemented for `usize`
   = help: the following other types implement trait `Div<Rhs>`:
             <&'a f32 as Div<f32>>
             <&'a f64 as Div<f64>> 
             <&'a i128 as Div<i128>>
             <&'a i16 as Div<i16>>
             <&'a i32 as Div<i32>>
             <&'a i64 as Div<i64>>
             <&'a i8 as Div<i8>>
             <&'a isize as Div<isize>>
           and 54 others

Version: 2.0.0
rust-1.66.0
FreeBSD 13.1

How does this compare to beets?

How does this compare to beets in terms of goals?

Idea: use `audiotags` crate

A fair amount of functionality in this crate is dedicated to extracting audio metadata. A recent announcement on Reddit for the audiotags crate, though, might mean that a lot of this logic can be outsourced to that crate, instead of having to reinvent a wheel here.

Thoughts? :)