Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support writing tags #183

Open
BeeDice opened this issue Jun 6, 2024 · 1 comment
Open

Support writing tags #183

BeeDice opened this issue Jun 6, 2024 · 1 comment

Comments

@BeeDice
Copy link

BeeDice commented Jun 6, 2024

My use case: I'm writing a PWA to manage a local library of music. I use jsmediatags to read tags client-side across multiple formats. As a user edits their library in the PWA, I'd like to offer the ability to write those changes back to the files on disk. Some client-side JS libraries like node-id3 support writing ID3 tags, but I would like to support as many tags as possible. Again, this is a PWA, so I can't use a server-side API to use taglib to get me updated bytes that I would then write back to local disk.

Proposal: rename the tag and file readers to indicate they support read/write. I suppose each reader would have their own way of "writing", each subclass implementing canWriteFile() and write(). Like, Xhr would send an OPTIONS request, Array/ArrayBuffer would update the in-memory arrays, Blob would create a new Blob with the updated tag data, and although I don't know Node or React files, I assume they have API's for opening the file in read-write mode. The tag readers probably remain unchanged, as they all can use the super class implementation of write(), which would create a byte array of UTF-16 or whatever the tag reader currently uses to read the tags.

@aadsm
Copy link
Owner

aadsm commented Jun 23, 2024

I'm still thinking about this. I need to get some time first to revisit some of the code and my own assumptions. It's not forgotten.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants