libu8ident VS tone

In programming languages it's much worse. Identifiers can either be unidentifiable, and if so everybody has a different opinion what "identifiable" means. Even the standard on identifiers, UTF-39, is buggy and has too many interpretations, leading to a complete disaster. https://github.com/rurban/libu8ident/blob/master/doc/c11.md

In punycode domain names it's quite simple still.

With other names, it's even worse. No-one cares. Linkers do not, username and filesystem drivers do not. The Apple HFS+ did care a bit one day, until someone in the higher ranks decided that no-one needs unicode security anymore and switched the new APFS to unsafe again.

No, it's definitely not safe to use unrestricted Unicode in a compiler. See https://github.com/rurban/libu8ident/ for identifier rules, and http://www.unicode.org/reports/tr55/ for much worse problems.

That's why unicode published the security guidelines and mechanisms to avoid such attacks. In 2004 already.

The problem is that nobody cared. Browsers invented punycode instead of following tr39, email ditto. But ok, at least something. Java did it, cperl did, rust did it.

Everybody else is vulnerable. Esp. most other programming languages, filesystems and login systems. https://github.com/rurban/libu8ident/blob/master/doc/c11.md

I'm maintaining such a library.

coreutils, diff, grep, patch, sed and friends all cannot find Unicode strings, they have no string support. They can only mimic filesystems, finding binary garbage. Strings are so rthi g different than pure ASCII or BINARY garbage. Strings have an encoding and are Unicode.

Filesystems are even worse because they need to treat filenames as identifiers, but do not. Nobody cares about TR31, TR39, TR36 and so on.

Here is an overview of the sad state of Unicode unsafeties in programming languages: https://github.com/rurban/libu8ident/blob/master/c11.md

Have you tried using ABP's own metadata tool and then using that to embed the metadata? They use tone. Not sure if it will help you with the m4bs containing mp4 streams - I've never tried dealing with that.

[2]: https://github.com/sandreas/tone#custom-scripted-taggers-experimental

Feedback is highly appreciated.

[1]: https://github.com/sandreas/tone

- LG G5 H850 (optional with Bang & Olufsen Hifi-Plus module) + Audiobookshelf + Substreamer

Let me cite my comment from https://news.ycombinator.com/item?id=32042780:

I use m4b-tool[1], tone[2] and audiobookshelf[3] together with an LG G5 H850 smartphone[8] with Bang & Olufsen Hifi-Plus Module for Audio Only and I am pretty happy with this config. For Music I use Navidrome[5] and Substreamer App[7]. Maybe I'll try out Jellyfin[4] or maybe Plex[6], but I really don't wanna go closed source.

I also thought about writing something self hosted in C# to have ONE solution for audiobooks, podcasts and music and started a small private project, but this will take a while until it is ready to release something...

You may ask: Why an LG G5 H850? Well, its relatively small and cheap (about 50 - 80 bucks used) it has an audio Jack, USB-C, you can change the battery, it can hold up to 2TB microSD storage, has an HiFi Plus module for audio enthusiasts and a descent screen. Besides that it can run lineage os...

Note: I'm the author of the first two projects :-)

[1]: https://github.com/sandreas/m4b-tool

[2]: https://github.com/sandreas/tone

[3]: https://github.com/advplyr/audiobookshelf

[4]: https://jellyfin.org/

[5]: https://www.navidrome.org/

[6]: https://www.plex.tv

[7]: https://substreamerapp.com/

[8]: https://en.wikipedia.org/wiki/LG_G5

> Very neat, I love it, I used to have a tool to do this but it's been ages and is now unmaintained.

Thank you :-) Glad to hear that.

> Just be sure to do input santization, since if someone else uses your code it could go from a very cool project to a backdoor that ends up on the front page for all the wrong reasons :-)

Good point. I think that the "scriptable" part needs special care regarding security issues, as well as the metadata-readers and JSON parsers. I don't want that to bite me in the neck because of a "malicious" file. Maybe it is worth to provide a responsible disclosure email and make a plan for security issues.

See https://github.com/sandreas/tone/issues/12