Skip to content
This issue has been moved to a discussionGo to the discussion

wasm version #289

Closed
Closed
@jerry7536

Description

@jerry7536

Thanks for your project!

I'm just wondering that if there is any plan for wasm version?

Activity

Serial-ATA

Serial-ATA commented on Nov 9, 2023

@Serial-ATA
Owner

Hello!

I'm not familiar with WASM. Is there anything in particular that doesn't work? Is it not able to compile?

jerry7536

jerry7536 commented on Nov 9, 2023

@jerry7536
Author

Noop, just curious about wasm version, no specific issues.

I'm not familiar with Rust, also new to wasm. I tried to build it myself and failed to execute at Javascript side

https://gist.github.com/jerry7536/b574989644a93ed674416955ef9f715b

my code sucks and an official wasm build would be great (just for query, decide by yourself)

Serial-ATA

Serial-ATA commented on Nov 9, 2023

@Serial-ATA
Owner

I haven't tried building on WASM, but an issue with the snippet is here:

let tagged_file = Probe::new(Cursor::new(buf)).read().expect("fail to read");

When using Probe::new, you'll need to call guess_file_type on it (or set_file_type if you already know the type). So this will always panic since Probe::read fails when no FileType is present.

jerry7536

jerry7536 commented on Nov 9, 2023

@jerry7536
Author

Thanks! that effects!

jerry7536

jerry7536 commented on Nov 19, 2023

@jerry7536
Author

Gist updated. New version successfully read the tag. Thanks!

milesegan

milesegan commented on May 6, 2024

@milesegan

Getting lofty to read tags in wasm is pretty straightforward now. Unfortunately though the browser APIs for reading parts of files are all async so there doesn't seem to be a way to pass this to the Read object that lofty's Probe::new wants. So in order to read the tag you have to read the entire file into memory first. For larger files this can be slow.

Is there any way around this other than adding an async API to lofty?

Serial-ATA

Serial-ATA commented on May 6, 2024

@Serial-ATA
Owner

Is there any way around this other than adding an async API to lofty?

I don't believe so. Lofty will need the entire file to be present in many cases, as sometimes times there will be tags written at the end or we have to guess the stream length. This is just something that'll have to wait for Keyword Generics.

milesegan

milesegan commented on May 6, 2024

@milesegan

Lofty will need the entire file to be present in many cases, as sometimes times there will be tags written at the end or we have to guess the stream length.

Interesting. So in cases like that reading the entire file first shouldn't take any extra time anyway.

I think I'll bundle up what I have now as a wasm-ified version of lofty that would make it easy to to read tags in a browser or nodejs app.

milesegan

milesegan commented on May 7, 2024

@milesegan

Some preliminary experiments suggest that even when reading the entire file into memory lofty in wasm is still faster than the pure JS library I've been using (https://github.com/Borewit/music-metadata) for smaller lossy audio files like opus. But the I/O is too heavy for larger lossless files like flac and it's much slower there.

Serial-ATA

Serial-ATA commented on May 7, 2024

@Serial-ATA
Owner

larger lossless files like flac and it's much slower there.

I'd imagine flac would be slower, since it currently eagerly allocates blocks. That's something I've been meaning to fix since it's less than ideal.

milesegan

milesegan commented on May 7, 2024

@milesegan

I have noticed that even compiling and running lofty natively (not in wasm) that reading tags from flac files is quite a bit slower than opus or aac. I just assumed it was because flac files required a lot more I/O but I confess I haven't looked into the details.

Serial-ATA

Serial-ATA commented on May 7, 2024

@Serial-ATA
Owner

Do you have benchmarks setup comparing Lofty and music-metadata? If they're decently far apart that's something I'd like to spend some time working on. Performance work just isn't something I've sat down and done, I really just focus on adding features and bug fixes right now.

milesegan

milesegan commented on May 7, 2024

@milesegan

I haven't done any proper benchmarks yet, just some observations using various methods to scan a library of about 15k tracks. For my primary use case, compiling lofty natively and using direct file access, lofty is very very fast. Running the same scan in a browser using music-metadata is at least an order of magnitude slower. Some very preliminary experiments with running lofty via wasm in the browser suggest it's also faster there at least on small, lossy files.

The main limitation with music-metadata is it only reads tags and doesn't support writing at all, hence my interest in getting lofty going in a browser environment.

Serial-ATA

Serial-ATA commented on May 8, 2024

@Serial-ATA
Owner

I don't have any experience with WASM, but I am always open to improving the experience with it. I'll probably get around to reducing the allocations in FLAC this week, which might help you out a little. The main blocker is keyword generics, though.

If you do end up doing some benchmarks, please do share them. I haven't done any benchmarks comparing Lofty to other libraries so that'd be nice to have. I'll move this over to a discussion.

Repository owner locked and limited conversation to collaborators on May 8, 2024
converted this issue into a discussion #400 on May 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @milesegan@Serial-ATA@jerry7536

        Issue actions

          wasm version · Issue #289 · Serial-ATA/lofty-rs