- 44comments
- 326comments
- 153comments
- 32comments
- 508comments
- 1comments
- 113comments
- 1comments
- 91comments
- —discuss
- 1comments
- 152comments
- 17comments
- 4comments
- 296comments
- 355comments
- 22comments
- 21comments
- 86comments
- 46comments
- 108comments
- 42comments
- 5comments
- 4comments
- 6comments
- 116comments
- 274comments
- 6comments
- 89comments
- 77comments
I wonder if this is small enough and performant enough to run on an Arduino. Or does it rely heavily on Intel instructions?
It looks like it's fast because it makes use of x86 and arm SIMD extensions, but you could probably get the scalar version to run on an arduino with some effort. It would likely be slow, though.
If you are looking at arduino audio applications, I would suggest either using a MP3 codec asic or pre-decoding to wav and compensating by using larger storage.
Yes, It's already been used on STM32F407 and ESP32.
Let me download mp3 files from the internet and run them through a completely new and untested parser and decoder. That sounds like a great plan.
Shouldnt really be a problem unless those mp3s have malicious code for that particular decoder
Please stop posting drive-by dismissive snark.
https://news.ycombinator.com/newsguidelines.html
Looks like it was inspired by http://keyj.emphy.de/minimp3/ and https://keyj.emphy.de/kjmp2/ , always good to see more people trying to implement multimedia codecs. The theory behind it all is not easy to understand, but in practice it turns into a bunch of arithmetic and table lookups.
That said, this one being floating-point and requiring intrinsics makes it less portable.
You absolutely correct, it's indeed inspired by Keyj`s minimp3. Float-point used because it's hard do with 4-byte fixed-point type and achieve ISO conformance. We must to use different dynamic ranges for different parts of decoder (i.e. emulate own floating point) or more than 4-byte fixed-point type. Only float-point support is needed, SSE/NEON intrinsics is not required and can be fully disabled by MINIMP3_NO_SIMD.
This is really cool and educational! How difficult is encoding relative to decoding?
Encoders usually harder, because, for example, you can't verify it using reference vectors (there no exact reference to compare with). Also encoders like h264 contains big part of decoder as well, because it must reconstruct encoded frame internally for motion compensation.