5 ms·

Show HN: Tone v0.0.4 – now hackable command line audio tagger, any feedback?

23 points by sandreas 4y ago

Hey HN, I just wanted to show the progress on my little (maybe useless) side project called tone[1] to get some qualified feedback. tone is a cross plattform command line audio tagger deployed as a single static binary without dependencies, so a wget should be enough to install on any platform (seems not to work on M1 Macs atm... if someone can help here I would really appreciate it). Features: - Supports most common formats (mp3, m4a, flac, ape, etc.) - Most common AND custom metadata fields - Chapter support - Embeddable pictures - Hackable (write your own taggers with scripting language) Thanks and have fun. [1]: https://github.com/sandreas/tone

22c 4y ago
At a glance it looks good to me, I can see you made it for audio books. Most of my tagging is done for Music. I know it seems fairly out of scope for this project, but do you have any plans to integrate updating tags from online sources eg. MusicBrainz, GoodReads etc. I could see myself using a tool like this if I could replace several tools with just this one. Right now I'm using Picard for music and Calibre for eBooks. Edit: I didn't read further enough, I like the custom tagger support. Some curation or perhaps a collection of "official" plugins for popular providers would probably help with adoption.
- sandreas 4y ago
  > At a glance it looks good to me, I can see you made it for audio books. Thanks for you feedback. Yes, audio books are the main purpose, but it should also work for music and even video in some cases (e.g. mp4). > Most of my tagging is done for Music. I know it seems fairly out of scope for this project, but do you have any plans to integrate updating tags from online sources eg. MusicBrainz, GoodReads etc. Yes, I have indeed. Since online resources are sometimes problematic regarding legal issues, I have to further investigate this, but things I plan to implement natively are: Audible, MusicBrainz, GoodReads, Bookbeat, Librevox, Opf (https://docs.fileformat.com/ebook/opf/ https://docs.fileformat.com/ebook/opf/), Cue-sheets, OverDrive and more > I didn't read further enough, I like the custom tagger support. Some curation or perhaps a collection of "official" plugins for popular providers would probably help with adoption. Yeah that would be awesome... tone is pretty new, but in the long term I plan native C# plugins to support: - custom taggers - custom dump (information output) - custom shell execution (ffmpeg to split, merge and apply filters to audio) As well as extensive scripting with JavaScript. Let's see how it goes :-) What also often helps a lot is the --path-pattern stuff. You can transfer filenames into tags that way very easily. A "rename" command would help to also rename files by tags. The following commands are planned on my list: *dump - show metadata in different formats (done) *tag - modify metadata by different sources (done) rename - rename files by tags split - split a file by chapters merge - merge multiple files to one with chapters convert - convert files to other formats keeping metadata
throwoutway 4y ago
This looks really great! Thanks for sharing! I've never heard of audio tags before, so Newbie question here: Is a metadata tag something that's embedded with the audio format (mp3, m4a, flac, ape, etc.)? So if I make a "bookmark" on an audiobook, can I embed that into the file itself? > extensive list of supported tags (additional fields, covers, chapters, etc.) Are these part of a standard? Anywhere I can read more about this?
- sandreas 4y ago
  Thanks for your feedback. > I've never heard of audio tags before, so Newbie question here: Is a metadata tag something that's embedded with the audio format (mp3, m4a, flac, ape, etc.)? So if I make a "bookmark" on an audiobook, can I embed that into the file itself? You did never hear of this? Really? Sure, that is exactly how it works... Bookmarks are sort of a more "personal" thing, but most metadata formats support custom "tags" to store anything you like. More common tags would be "artist", "title", "album", "description", "lyrics", etc. > Are these part of a standard? Anywhere I can read more about this? Yeah sure. Id3v2 would be a good start, since it is used for some formats: https://id3.org/id3v2.3.0 https://id3.org/id3v2.3.0 Then there is APEvc: https://wiki.hydrogenaud.io/index.php?title=APEv2_specification https://wiki.hydrogenaud.io/index.php?title=APEv2_specificat... MP4 is native tagging: https://en.wikipedia.org/wiki/MPEG-4_Part_14 https://en.wikipedia.org/wiki/MPEG-4_Part_14 etc. etc. too many to link them all. The implementation tone uses is https://github.com/Zeugma440/atldotnet https://github.com/Zeugma440/atldotnet
  - loxias 4y ago
    Correction, ID3 is a good start. ;) Id3v2 is ... much more. Unrelated, I like your project! Nice! (I'm not entirely sure what your tool does that isn't done by the standard tagging tools id3, id3tool, id3v2... but that's NOT a criticism. I wrote my own multithreaded-resumable-forensic `dd` and a homegrown replacement for `tar` for instance) I'm not a "power user" or developer of _tag_ related stuff, but under your Future Plans, the "split" and "merge" features (and even more advanced things like that...) is the sort of code I do. I've written "that kind of tool" at least twice before. A few years ago as a one off for a client doing movie scores with many many TB of multitrack (24 channels) audio, and wanted something HIGH performance for tunable and batchable splits, silence detection, merges, as well as automatic clustering (!). Those split/merge features, that, I'm guessing you're planning on implement by requiring ffmpeg _AND_ using another library just to wrap it? I'd do in native code and, as a result, performance would be orders of magnitude better. I don't use windows (at least, I'm not willing to use windows for any 'pro bono' work ;-) ) but if you were to write your tool in C or C++ instead, or perhaps... have a common API layer of sorts... I bet you'd find plenty of people (including me!) who wouldn't mind, and actually enjoy, helping you out by "gifting" some fast and MUCH leaner solutions for any and all of the audio processing work that it looks like you're planning on needing to shell out to other things to accomplish.
klntsky 4y ago
Are there features not covered by kid3?
- sandreas 4y ago
  > Are there features not covered by kid3? I don't know the whole feature set of kid3, but here are some thoughts: - its scriptable with JavaScript - chapters for id3 and mp4 supported out of the box - support for exotic tag fields (©mvn movement name in mp4, see <https://kid3.sourceforge.io/kid3_en.html#frame-list>) - custom tag fields (ASIN, TXXX, ----:) - monolithic binary Of course it is no competition to kid3, but since it is relatively new, this really does not surprise me :-)
dontbenebby 4y ago
Very neat, I love it, I used to have a tool to do this but it's been ages and is now unmaintained. 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 :-)
- sandreas 4y ago
  > 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 https://github.com/sandreas/tone/issues/12
  - dontbenebby 4y ago
    Sounds like you're detail oriented, good luck with your project. Here's a good starting point for reading about common meta level patterns in software vulnerabilities so you can avoid reinventing the wheel https://owasp.org/Top10/ https://owasp.org/Top10/
    - sandreas 4y ago
      > Sounds like you're detail oriented, good luck with your project. Yeah that may be true... :-) Good old owasp will help out here. Thanks for your feedback, I really appreciate it.
      - dontbenebby 4y ago
        No worries, gotta do something while a big software update installs and my laptop charges (other than talk the barista's ear off, hehe)

sandreas 4y ago
> Correction, ID3 is a good start. ;) Id3v2 is ... much more. You're absolutely correct :-) > Unrelated, I like your project! Nice! Thanks for your feedback, you're welcome... > (I'm not entirely sure what your tool does that isn't done by the standard tagging tools id3, id3tool, id3v2... but that's NOT a criticism. I wrote my own multithreaded-resumable-forensic `dd` and a homegrown replacement for `tar` for instance) Not much really, it is just a tool that supports multiple platforms and multiple metadataformats all in one static binary AND supports chapters... it may be a bit more versatile and easy too use than existing tools. But that is opinionated. > wanted something HIGH performance for tunable and batchable splits, silence detection, merges, as well as automatic clustering (!). Those split/merge features, that, I'm guessing you're planning on implement by requiring ffmpeg _AND_ using another library just to wrap it? I'd do in native code and, as a result, performance would be orders of magnitude better. Yes, I plan to use `ffmpeg` for the first part, but also include `fdkaac` and maybe `sox` or other audio specialist tools to provide better audio. My plan is also to integrate a dependency downloader, that does not want you to install the dependencies yourself, but does everything for you. I'm the author of `m4b-tool`[1], which has also split, merge and silence detection, so I have a little experience in exactly this topic you are talking about (tone is planed as long term successor of m4b-tool, but this will take time). I will use a library called CliWrap[4] to integrate shell execution though, but do it multithreaded to provide more performance. > I don't use windows (at least, I'm not willing to use windows for any 'pro bono' work ;-) ) but if you were to write your tool in C or C++ instead, or perhaps... have a common API layer of sorts... If I understood this correctly: C# is not Windows-Only any more, and it is pretty fast on all platforms. It provides Ahead of Time Compilation and a so called self-contained binaries working without any C# runtime or VM... using github actions I provide a full featured monolitic executable binary, but I could also provide a library. C# is even capable of and using unmanaged code, writing drivers and embedded stuff, like RPi... I think it is not a bad language to start such a project, but at least the best I know well enough ;) > and actually enjoy, helping you out by "gifting" some fast and MUCH leaner solutions for any and all of the audio processing work It would really be nice to find some collaborators, thank you. There are some C# audio processing libraries out there (like NAudio[2] or cscore[3]), but currently windows only or pretty complex. We'll see... :-) This was very helpful. Thanks again. [1]: https://github.com/sandreas/m4b-tool https://github.com/sandreas/m4b-tool [2]: https://github.com/naudio/NAudio https://github.com/naudio/NAudio [3]: https://github.com/filoe/cscore https://github.com/filoe/cscore [4]: https://github.com/Tyrrrz/CliWrap https://github.com/Tyrrrz/CliWrap