• Probably preferable to use Shorten for the namespace name rather than SHN.
• The coding style / naming for shnfile is very different from TagLib's style. Was that code pasted from somewhere else? There's no copyright statement indicating such.
• String literals obviously can't be in single quotes.

In shnfile there are quite a few things that could be cleaned up a bit (e.g. using TagLib's ByteVector instead of arrays that are created with new. Quite a few things could be constexpr instead of const, etc., but I thought I'd wait to hear where that code's actually from before going into too much detail.

• Probably preferable to use Shorten for the namespace name rather than SHN.

I went back and forth on this. I couldn't find a clear standard in TagLib for the naming. File extensions seemed to be common for namespace names- Monkey's Audio uses APE, Musepack uses MPC, but True Audio uses TrueAudio.

• The coding style / naming for shnfile is very different from TagLib's style. Was that code pasted from somewhere else? There's no copyright statement indicating such.

The code is modified from a Shorten decoder I wrote in Objective-C++ a few years ago. The naming conventions are a bit of a mishmash as I've ported portions back and forth to different languages several times including this pared-down port to C++. I was generally inspired by the original shorten written by Tony Robinson as the reference for the Shorten format.

• String literals obviously can't be in single quotes.

Those are four-character codes (integers masquerading), not string literals, but they can easily be changed to integers.

In shnfile there are quite a few things that could be cleaned up a bit (e.g. using TagLib's ByteVector instead of arrays that are created with new. Quite a few things could be constexpr instead of const, etc., but I thought I'd wait to hear where that code's actually from before going into too much detail.

It looks good to me. I just added a few commit with stylistic changes, you can still remove them if you do not agree.

Thanks for the review- I am fine with those changes. I pushed another commit with some additional explicit types in an attempt to further standardize and group constants.

What is your opinion on SHN vs. Shorten for the namespace name?

What is your opinion on SHN vs. Shorten for the namespace name?

Probably, Shorten would be more consistent with most (but not all) of the other namespace names.

If there are no further review comments or objections in the next few days I will squash and merge this into master.