Metadata as separate package?

[Volodymyr-13]

@sbooth

Hi Stephen,

Thank you for the SFBAudioEngine repo!

We previously used AudioKit for our production app and needed a reliable metadata reader/writer, which led us to your library. After extensive testing in our iOS app, I can confidently say that SFBAudioEngine Metadata reader/writer outperforms any other libraries we’ve tried. Some caused crashes, while others failed to read or write metadata properly. Your repo handles everything exceptionally well and remains stable.

I have a question: could SFBAudioEngine be split into separate packages which can work separately? For example, the audio format conversion functionality seems like an additional feature. Starting from that, it's possible to create a separate package for the metadata reading/writing module also? Since we only need the metadata functionality, importing the entire engine brings in a lot of unused code and libraries. I understand this might not have been part of your initial design, but I’m curious if this split could be feasible. It might also help isolate potential issues in the future...

Additionally, I noticed that some links in the readme are broken: https://github.com/sbooth/SFBAudioEngine?tab=readme-ov-file#properties-and-metadata.

P.S. I would love to see a fully Swift codebase for the engine (excluding the C++ bindings). I understand the choice to use ObjC, but in these modern times, Swift represents the future, and we are using it every day. While I appreciate the use of “older” languages, we should focus on moving into the future.

That said, I’m truly grateful for the work you’ve done! I actually really like ObjC, it’s where I began my development journey.

[sbooth]

I'm happy to hear that the metadata portion of SFBAudioEngine is working well for you. I think most of the credit should go to TagLib, though!

I have thought about splitting the metadata handling into a separate package. As things stand right now the only shared code between the player and metadata is for Shorten since that is a format not supported by TagLib. I'm interested in adding Shorten support to TagLib but that isn't a project I've started. If that were to happen I would seriously consider splitting the package into two (or three, as you suggest) separate packages.

A full Swift codebase would be nice but isn't possible with the current state of Swift-C++ interoperability. As an example, the MAC decoder requires IO methods that inherit an abstract C++ interface which isn't possible to write in Swift. So some level of Obj-C++ glue is required.

[Volodymyr-13]

I have thought about splitting the metadata handling into a separate package. As things stand right now the only shared code between the player and metadata is for Shorten since that is a format not supported by TagLib. I'm interested in adding Shorten support to TagLib but that isn't a project I've started. If that were to happen I would seriously consider splitting the package into two (or three, as you suggest) separate packages.

Sounds great! I’ll stay tuned for updates on this. Thanks!

A full Swift codebase would be nice but isn't possible with the current state of Swift-C++ interoperability. As an example, the MAC decoder requires IO methods that inherit an abstract C++ interface which isn't possible to write in Swift. So some level of Obj-C++ glue is required.

Yeah, excluding the C++ bindings, but I was referring to all the other engine classes. From what I see, it’s mostly in Objective-C. What I’d really love is a modern, lightweight engine that can handle most media formats and is written in Swift. 👍🏻

[Volodymyr-13]

.... for Shorten since that is a format not supported by TagLib. I'm interested in adding Shorten support to TagLib but that isn't a project I've started. If that were to happen I would seriously consider splitting the package into two (or three, as you suggest) separate packages.

Hey @sbooth, perhaps it could be split without that specific format? Maybe create another package just for it? To be honest, it's a super rare format, and most people don't even know it exists. :D

[sbooth]

I don't plan on removing Shorten support. I'm also not sure how much of a benefit splitting the packages would actually provide.

[Volodymyr-13]

I don't plan on removing Shorten support. I'm also not sure how much of a benefit splitting the packages would actually provide.

Ah, I see, I’m not suggesting removing it. I meant that Shorten is a relatively rare format, and it would make sense to treat it as such.

Here’s our situation: we’re using AudioKit for our production app, and we only use SFBAudioEngine for reading/writing metadata tags. However, using the entire engine repo for this purpose is quite overwhelming.

That’s why I believe splitting SFBAudioEngine into a separate repository like for example SFBAudioTags could be really beneficial. It would allow us to only include the metadata reading/writing component, making it much lighter and more modular for other people, which could add more like testers/reporters/contributors to that repo.

This separation would also streamline the process of fixing or updating components like TagLib independently(updates/fixes), which could speed up the development cycle. For example, any bug with reading tags, we could address faster/separately and without being tied up with the entire engine code.

Moreover, isolating the metadata functionality would make the whole project easier to maintain, test, and update. We would be able to contribute more effectively as well, which is important to us. Users have reported issues with certain tags not being read, and our goal is to resolve this as quickly as possible. Currently, these issues are more difficult to address because they’re locked within the engine code, which complicates the process of fixing, testing, and updating.

By creating a separate repo for metadata handling, you would not only improve the flexibility of the project but also create a more modular setup that could attract more contributions from the community, particularly from us, as we’re highly motivated to contribute fixes.