wasm version

[jerry7536]

Thanks for your project!

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

[Serial-ATA]

Hello!

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

[jerry7536]

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]

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]

Thanks! that effects!

[jerry7536]

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

[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]

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]

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]

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]

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]

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]

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]

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.