You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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?
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.
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.
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.
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.
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.
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.
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
Activity
Serial-ATA commentedon Nov 9, 2023
Hello!
I'm not familiar with WASM. Is there anything in particular that doesn't work? Is it not able to compile?
jerry7536 commentedon Nov 9, 2023
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 commentedon Nov 9, 2023
I haven't tried building on WASM, but an issue with the snippet is here:
When using
Probe::new
, you'll need to callguess_file_type
on it (orset_file_type
if you already know the type). So this will always panic sinceProbe::read
fails when noFileType
is present.jerry7536 commentedon Nov 9, 2023
Thanks! that effects!
jerry7536 commentedon Nov 19, 2023
Gist updated. New version successfully read the tag. Thanks!
milesegan commentedon May 6, 2024
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'sProbe::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 commentedon May 6, 2024
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 commentedon May 6, 2024
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 commentedon May 7, 2024
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 commentedon May 7, 2024
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 commentedon May 7, 2024
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 commentedon May 7, 2024
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 commentedon May 7, 2024
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 commentedon May 8, 2024
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.