Perhaps _NO_MACK anywhere in the comment would do.

This needs to be validated to see if this would actually speed things up with a couple of thousand files, but it doesn't sound unreasonable that it might. Possible granularities:

• Track (probably about right since we may have may fixers)
• Fixer (this is probably going to slow things down since each fixer is very fast)

There are currently some limitations with regexes, especially that they don't support lookahead/behind assertions in rust-regex. fancy-regex supports these but has no .replace(), which is a pain in the arse since that's most of what we want to do.

Maybe we should just write a parser with nom.

At the very least, the readme and --help need enhancement when we're coming to 1.0.

Right now we only ensure that whatever is within the "feat" block is enclosed correctly and has the right feat verb, but not that it uses "and" (instead of "&") and that it uses the Oxford comma.

https://doc.rust-lang.org/cargo/reference/manifest.html

This is somewhat difficult and is outside the current provided infrastructure because it requires one to do some checks first to see if this looks like something that should be split out. For example "Simon & Garfunkel" should stay the same, but this should not as "Die Lit" is already attributed to the primary artist:

• Artist: Playboi Carti & Nicki Minaj
• Album: Die Lit
• Track: Poke It Out

should become

• Artist: Playboi Carti
• Album: Die Lit
• Track: Poke It Out (feat. Nicki Minaj)

...because "Die Lit" being in both shows this is really just a feat tag.

Possible other things to look for:

• &
• and
• feat[uring]
• vs
• with

https://wiki.musicbrainz.org/Style/Language/English

This is obviously not foolproof as some of these rules require evaluation of the meaning of the title in context (and it only applies to English), but we can at least do the basics.

This also might be worth extracting to its own crate.

Using regexes (for example) is fairly logical for many fixers, but it's hard to validate visually that they work properly and don't regress. Adding tests would help avoid that.

It's probably worth also using quickcheck instead of static examples.

The most major one is file renaming based on tags, which should be done after tag cleanup. There are others, though, like making sure case insensitive matches for the same artist or artist/album pair have the same capitalisation.

Right now main is a cavalcade of nested conditions and matches. This should be cleaned up.

I had intended to use a closure for this, but due to there not being any abstractions over taglib's Rust FFI bindings, we end up in a bit of a pickle as we end up having to borrow tags twice if we want to pass both (say) tags.album and tags.set_album to a function.

I'm not yet entirely certain how to overcome this in a DRY way, so it's implemented manually for now. This needs cleanup for sure.

We can now run with cargo test.

Right now it seems the vast majority of our runtime is in taglib deref/malloc/free. This makes me think it might be better to just store the tags in Track.

After 429084d we now use clean_part for each format, but this isn't quite right -- it should be used for each directory we got.

This is a bit complicated since we don't want to sanitise the user string, but.

Looks like taglib is in homebrew, at least.

Pros:

• The current way of passing around tags is pretty stilted due to the very C-like API provided by the taglib bindings. This would likely allow some better code structure and avoid the stilted .save() handling now.
• taglib has some recent C-specific CVEs (although they don't look too worrying for our threat model).

Cons:

• Right now it seems there's no generic tagging library for Rust, so we'd likely have to use separate libraries for separate tag types and abstract over them.
• Pure Rust tagging libraries seem not super featureful compared to existing C solutions right now, resulting in issues even with fairly "normal" seeming mp3 files (eg. polyfloyd/rust-id3#27)

We should rename things to artist/album/trackno title.ext. We need to work out how to specify the base dir, though.

This could be:

• Trailing whitespace
• Leading whitespace
• Multiple whitespaces between words

Right now we offer no way of showing to the user what we would do before we do it. We also don't actually show what we did even if we did do it.

At its most basic level, this is basically just gating .save(), but that's not very useful by itself. We should also implement something which prints out the before and after for changed tags.

Keeping the "before" around probably requires some shenanigans, since we'll need to extract them from the taglib::Tag object before modification. It would be ideal not to just extract them all, but only clone when we know that we're actually going to make a change. Maybe Cow can help here.

If showing the before turns out to be too much of a burden, we should at least just show the after with the affected filename.

Right now we use .truncate() for sanitisation, but this will panic if not at a char boundary. Perhaps collect into a Vec?

Hello, what are your thoughts on also ordering assets like lyrics (per file) covers (per album) maybe artist pics, etc. Are these in line with mack or don't matter? What about embedding that info?

I just found out about this tool, always seemed to want something like this and almost started writing something similar (dummy me).

Right now we only allow recursing a directory, but we should also allow running on specific files.

For the sake of fast development, there are probably still some .unwrap() and .expect() around. Ones still existing should be justified in an .expect(), the rest should be handled better.

• Artist: X feat. Y
• Title: Z

Becomes

• Artist: X
• Title: Z (feat. Y)

Right now you can only pass one dir, but we should allow multiple.