search

sbooth / SFBAudioEngine

A powerhouse of audio functionality for macOS and iOS
https://sbooth.github.io/SFBAudioEngine/
MIT License
560 stars 87 forks source link

Metadata as separate package? #362

Closed Volodymyr-13 closed 3 days ago

Volodymyr-13 commented 1 week ago

@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 commented 6 days ago

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 commented 5 days ago

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. 👍🏻