DIY MP3/OGG/FLAC player, feasible? - Page 1
Forum section: electronics / projects

author: Kingdud
author_rank: Newbie
timestamp: September 27, 2024, 11:55:39 pm
content: This is something of a 'get out of depression' project. Lots of mental loops saying it won't work for various reasons. So...yeah. I have a computer science degree and programmed in C for years, but never device drivers/embedded stuff. I know enough about electronics to be dangerous (to myself and components). I replaced the capacitors in a monitor after they failed, matching voltage and farads; that was pretty simple. In terms of tools I have a cheap $20 soldering iron and a 150W bench top power supply (constant voltage or amperage, but not both at the same time), and that's about it. No O-scope, or other fancy tools.Right now, I have a Sandisk Clip Zip that I use to play both music and podcasts. It kinda sucks, even after I flashed it to use Rockbox. It plays either podcasts, or music, just fine, but it can't remember where I was in a podcast when I switch to music or charge it. Annoying. Also, one day, its battery will die. That brings us to question 1:It uses a 3.7v pouch cell battery (for teardown) and...am I nuts for thinking i could just hot wire that to an 18650 holder and use the 18650 instead? I'd recharge it via a separate device I bought specifically to charge 18650s. I'd 3d print a new case, in that event. But, electrically...I can't see any reason that wouldn't work, but this is also not my area of expertise.Question 2: I only ever plan to build 1 of these. It would cost me $50 to buy another Clip Zip at this point, and I don't know whether the better option is to just buy a second one (one for music, one for podcasts) or try to DIY my own. I can think of all sorts of other projects I could do if I got over that initial hump of learning...what do you even call raspberry pi nano/arduino/esp32 type stuff? Mini-compute? Embedded? idk. Thinks like BBQ automation, home automation, remote sensors or detectors...baby steps. baby steps. Sorry, my question: Is it more rational to build my own, or get something pre-built?If I went DIY, here would be my design criteria:Must play: MP3, FLAC, OGG. (my audio is already in these formats, and I don't feel like re-encoding everything).Power source: 1 or more 18650 Lithium Ion cells (I harvest them from tool batteries, they are my standard for powering stuff unless I *really* need a different solution; I like being able to just swap batteries rather than needing to plug the device itself in to charge) -- no charging circuit needed, only discharge.Buttons for play/pause, volume up/down, back/forward, select.Some form of display; will spend 99.999% of its lifetime off, only needed when I want to check the track name or battery %TRRS / TRS port for headphones, capability to handle 50 ohm headphones.Removable storage (microSD, USB, doesn't matter to me) so I can swap audio files easily (no wifi/bluetooth pls)I'm pretty sure I can handle the software side once I get hardware that works together. I have no idea how I'd debug this thing though. When I ask chatGPT about this problem, it suggests getting either a Raspberry Pi Nano or ESP32 and using those, indicating the raw CPU power can decode those formats alone. Other times it suggests using a VS1053b shield. I've also found people on reddit trying to do this with an arduino and a vs1053b shield for it.I guess...I see a lot of people who want to do this particular project, and nobody saying "I finished it! Here it is!" Am I missing something? Is this devilishly complex for some reason I can't find? Do people get it working and forget to post how they did it? Is it all but plug and play and I'm overthinking? Is there a path forward that makes more sense?Thanks for reading and helping.

author: squadchannel
author_rank: Frequent Contributor
timestamp: September 28, 2024, 12:10:43 am
content: It used to be a common article in the past. There was a DAC for audio with a MP3 decoder in it, controlled by an Atmega8, etc....VS1011, VS1053, and so on.Considering the performance of today's microcontrollers, it would be feasible with a single chip.I think VLSI chips are outdated.MP3, have to be decompressed, so everyone used WAV in the past to make it easier.I knew it. elm-chan made it.http://elm-chan.org/works/mp3/report_e.htmlhttp://elm-chan.org/works/gmp/report.htmlhttp://elm-chan.org/works/cube/report.htmlhttp://elm-chan.org/works/pcmp/report.htmlhttp://elm-chan.org/works/sd8p/report.htmlBy the way, there is now a module called DFPlayer.It can be controlled via UART, so I think it is easy to make.It doesn't have the difficulty of a bare chip, though, such as controlling registers.

author: jbb
author_rank: Super Contributor
timestamp: September 28, 2024, 01:30:34 am
content: I’ll bet some flavour of ARM Cortex M has a) enough juice to do MP3 decoding in software and b) a digital audio (I2S??) output for an audio DAC.Of course, the time taken to cook something up will ‘cost’ vastly more than buying another player. So just have a think: will you enjoy the journey to get there :-) ?

author: ataradov
author_rank: Super Contributor
timestamp: September 28, 2024, 01:53:37 am
content: The absolute minimum MCU that can feasibly decode medium-quality MP3 is going to be Cortex-M4 running at 120 MHz+. And it is going to be a challenge to make that work.I would certainly stick with VLSI ICs. They are easy to use and are purpose designed. Then use whatever cheapest MCU you can do to the UI.Usually in cases like this, the battery is a limiting factor, but if you are starting with 18650, then it is not really an issue.

author: Smokey
author_rank: Super Contributor
timestamp: September 28, 2024, 02:02:35 am
content: I think ESP32 module can decode MP3 on the fly. Modules come with up to 16MBytes of flash. Just need an output driver. Probably do the whole project in arduino land from examples.

author: ataradov
author_rank: Super Contributor
timestamp: September 28, 2024, 02:08:09 am
content: Yes, they have about Coretx-M4 class processor running at 160+ MHz. There is no reason it can't decode MP3s.The issue I see here is support for various format options, like VBR. I know there are some commercial MP3 libraries that are well optimized, but cost a bit of money. And I don't know if open source ones are designed to handle all that variability. I looked at that a very long time ago, and back then they were mostly designed to play back files you control, so they could set strict limits for the bit-rate and sampling parameters. This is not going to be the case for random MP3s you download from the net.

author: Postal2
author_rank: Frequent Contributor
timestamp: September 28, 2024, 04:18:00 am
content: Quote from: ataradov on September 28, 2024, 02:08:09 amI know you recommend assembler for writing UI and DSP, but not everyone has enough knowledge for that.Quote from: Kingdud on September 27, 2024, 11:55:39 pmYou need to search for the keyword "bluetooth module".https://aliexpress.com/item/1005001992286837.htmlhttps://aliexpress.com/item/1005007403101166.htmlhttps://aliexpress.com/item/1005007426609602.htmlYou need to contact the seller about FLAC and OGG support. The thing is that the chips support these formats, but not in all versions. Old versions may not support OGG.All you have to do is cut out a box from plywood (using your knowledge of assembler, of course).Here, OGG is specifically declared separately:https://aliexpress.com/item/1005006163880568.htmlBut this one doesn't say OGG, you have to ask, although it looks the same:https://aliexpress.com/item/1005006138267255.html

author: ataradov
author_rank: Super Contributor
timestamp: September 28, 2024, 04:41:48 am
content: Oh look who's here. The thread will not go to shit.Don't put words in my mouth.

author: Postal2
author_rank: Frequent Contributor
timestamp: October 18, 2024, 01:18:50 am
content: The board in the photo does not support OGG. Moreover, it had a faulty quartz, but fortunately it is 24 MHz. The marking of the chip is erased, mp3 plays normally. If anyone is interested.

author: NiHaoMike
author_rank: Super Contributor
timestamp: October 18, 2024, 02:44:55 am
content: Quote from: ataradov on September 28, 2024, 01:53:37 amThe iPod does it with an old 80MHz ARM chip. It can even handle Opus, but only without EQ enabled.Someone really needs to make an open hardware audio player that runs Rockbox, it's sort of already fading into obscurity as the hardware to run it on is becoming less common. One that's in the form factor of one of those single 18650 portable phone chargers would be great, accepting a micro SD card for storage. Bonus points if it also works as a flashlight and power supply.

author: ataradov
author_rank: Super Contributor
timestamp: October 18, 2024, 04:22:06 am
content: Quote from: NiHaoMike on October 18, 2024, 02:44:55 amiPod uses dual core device specifically designed for audio applications. I don't know how much hardware acceleration is there, but dual core helps for sure.I would also expect them to have optimized the hell out of that firmware. I'm not sure any freely available decoders are well optimized.

author: Postal2
author_rank: Frequent Contributor
timestamp: January 08, 2025, 10:09:00 pm
content: The board in the photo supports OGG.Video formats also tested:Video: MPEG4 Video (H264) 1024x552 (1019:552) 23.98fps Audio: AAC 48000Hz stereo 1536Kbps Video: DivX 5 640x480 25.00fps [Stream 00]Audio: MPEG Audio Layer 3 48000Hz stereo 192Kbps [Stream 01]Also firmware for the player and display controller.

author: amyk
author_rank: Super Contributor
timestamp: January 08, 2025, 10:12:05 pm
content: The really cheap modules based on JieLi SoCs should be sufficient to do what you want (many have Bluetooth too.)

author: Postal2
author_rank: Frequent Contributor
timestamp: January 08, 2025, 10:18:13 pm
content: Quote from: amyk on January 08, 2025, 10:12:05 pmI bought it too, it's still in a bag. I'll check it and post a photo.

author: DavidAlfa
author_rank: Super Contributor
timestamp: January 10, 2025, 12:34:05 am
content: Modify rockbox for your needs?

author: Postal2
author_rank: Frequent Contributor
timestamp: January 11, 2025, 04:29:57 am
content: The boards in the photo do not support OGG.

author: DavidAlfa
author_rank: Super Contributor
timestamp: January 11, 2025, 05:03:23 am
content: Quote from: ataradov on September 28, 2024, 01:53:37 amAs long as you have FPU it can be done with much less power.I'm decoding mp3 with a stm32f411 running at 96MHz, reading the files from a USB drive, streaming the output through i2s, while also attending an interrupt-drive spi peripheral and other stuff, all done in unefficient HAL and relatively small audio buffers (Double buffering, each holding ~25ms audio samples).Setting up the Spirit MP3 lib provided by ST is a child's game!If you want to have a look:https://github.com/deividAlfa/STM32F411-Black-pill-USB-WAV-MP3-player/I'll check how slower I can go before getting buffer underrun.Edit:I could got down to 16MHz *without any compiler optimizations* and still played 320Kbps MP3 just fine!At 12MHz it started to struggle, but did ok with optimizations.It's the FPU magic!Other formats are much more expensive to process, though.320KBps MP3 might use more storage than other formats for the same quality, but can be decoded much easier, storage is cheap so the tradeoff might worth it.

author: phansel
author_rank: Contributor
timestamp: January 13, 2025, 06:36:31 pm
content: Quote from: Kingdud on September 27, 2024, 11:55:39 pmYou can just do things and ignore what the GPT says. Those obstacles are more social than real.

author: coromonadalix
author_rank: Super Contributor
timestamp: January 13, 2025, 07:12:11 pm
content: and when they say finished like tons of Youtube, they don share zits just a teaser.but i can understand the work involved, and some gets their project stolen ...

author: Postal2
author_rank: Frequent Contributor
timestamp: January 14, 2025, 01:33:36 am
content: Quote from: coromonadalix on January 13, 2025, 07:12:11 pmWhen I was 6 years old, I passed off someone else's project as my own (I made it based on someone else's description, but said that I came up with it myself). I was very pleased when everyone praised me, I still remember it. It gives impetus to independent work. Therefore, I understand people who pass off someone else's work as their own, and I even specifically indicated that it is possible to do this with my projects, passing them off as their own. Therefore, if I wrote somewhere that something was stolen from me - it is just humor (on my part).

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 14, 2025, 03:40:09 am
content: This is doable with a Cortex-M4(F) for sure even at relatively low frequencies as DavidAlfa mentioned. Flac should also be no problem. Ogg Vorbis, probably as well.For sure if you're not the king of optimization and want more margin, you could just consider a Cortex-M7 for more RAM and computing power. If this isn't for a product, but just a prototype (or a few), you could just use a Teensy 4.x board. It has everything including a micro-SD socket - you'd just need an external DAC/headphones amp which can be found as small breakout boards if you don't want to design this yourself. The main issue will be the power consumption, if that's battery-operated and if it must be very small and light. Otherwise, you should be plenty with a budget of ~100 mA (for a Teensy board) when playing (maybe less, I'm probably being on the pessimist side), which would be 10 hours of play time on a 1000 mAh battery, which is still relatively small and light. Just to give some perspective.But yes, a Cortex-M4 should be fine, and something like the STM32L4 series (@80 MHz, should be plenty as again DavidAlfa said) would yield a much lower power budget yet.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: January 15, 2025, 05:50:46 pm
content: MP3 started in 1991https://en.wikipedia.org/wiki/MP3and "published" in 1993, same year as Intel released it's Pentium processor:https://en.wikipedia.org/wiki/Timeline_of_computing_1990%E2%80%931999And that run at 60MHz, meaning plenty of 80486 pc's were used to decode MP3's.Quite mind boggling that today's microcontrollers can be more powerful then the PC's from that era.The "easy way out" for a project like this is to use one of the many SBC's that can run an off the shelf Linux variant. All the luxury of a full OS, with drivers for everything, audio players, file system, file exchange / update (just use scp, or any sort of standard networking / file sharing software). And also scripting capabilities to customize (there are command line players which are easily scriptable too). For smaller size, there are the compute modules, but these don't have room for plugs and such.For microcontrollers there are (also open source) libraries to lower the computation overhead, some work with fixed point, or may take some shortcuts for decoding, which may influence audio quality, and you may have problems, depending on how the encoding was done in the original files. Some microcontroller vendors have third party libraries for decoding various audio formats, but they tend to be commercial / not free.As SiliconWizard already mentioned, Teensy 4.x may be a good choice. That thing runs at 600MHz, and should have plenty of processing power. Teensy 4.x is also popular for other audio related projects, such as building synthesizers.Quote from: Kingdud on September 27, 2024, 11:55:39 pmWhat's the problem with re-encoding?Such a task is easily scriptable, and MP3 versus FLAC is quite a quality / size tradeoff.I use FLAC nearly exclusively, but from a several TB HDD, size is no problem. (12TB disks are the lowest cost per storage unit these days). If I wanted smaller sizes, for example for a portable player, I would of course keep my original FLAC files, but re-encode everything to a smaller format (probably OGG) in a separate directory tree. It's a bit inconvenient to have two trees with audio in different formats, but the second can be created and updated from a script quite easily. On the other side, managing multiple different audio decoding libraries (and their idiosyncrasies) on a small uC can easily suck up a lot of time to get it working reliably.If (battery) power (and battery size) is of great concern, then a chip like the VS1053 is probably one of the better DIY solutions. I bought a few of these long ago, never used them, just glanced over the datasheet. From what I understand it's a DSP, and I'm not sure how audio specific it is. Apparently you can upload different firmware images to it, depending on what audio format you want to decode. I don't know if it's doable to write your own application for this chip.

author: coromonadalix
author_rank: Super Contributor
timestamp: January 15, 2025, 06:23:41 pm
content: flac is excellent to re encode if you don't do joint stereo and go over 192 or even higher ratesi have tons and tons of audio, it is minimum mp3, flacogg and other sources types are converted, and in some cases i do levels normalization if needed

author: mariush
author_rank: Super Contributor
timestamp: January 15, 2025, 06:31:37 pm
content: I wouldn't touch mp3 in 2025 ... opus provides much better quality than both mp3 and the more standard aac formats and it's open source. It's probably around 2x more complex to decode than mp3

author: Siwastaja
author_rank: Super Contributor
timestamp: January 15, 2025, 06:44:18 pm
content: Some Cortex-M7 @ 400MHz or more and a lot of flash memory is a decent idea because that should bring you to a position where most existing open-source implementations written in C without any specific "embedded" mindset should just compile and run. Sure it costs a little bit more but for a hobby one-off, that does not matter. You can then later take optimization as the next challenge.General purpose computer (single-board computer) is of course the easiest way out, but is that fun anymore? I mean, it's just a small computer. Of course you can play mp3 files on a computer. So maybe too little challenge?

author: Siwastaja
author_rank: Super Contributor
timestamp: January 15, 2025, 07:02:50 pm
content: Quote from: mariush on January 15, 2025, 06:31:37 pmI have heard similar stuff so much in past that I give zero value to this.JPEG2000 was supposedly sooo much better than the "stone-age" JPEG, yet nearly every example demonstrates that given same file size, JPEG2000 looks actually worse with picture detail disappearing, sometimes quite significantly so.I remember in early 2000's when Ogg vorbis was brand new thing and all cool kids were "transitioning" to it. Supposedly you would be able to compress music to 64 kbit/s with acceptable quality. In reality quality at 64 kbit/s was equally crap to mp3 at 64 kbit/s. I did quite some many test encodes and blind testing myself and in the end mp3 encoded in joint stereo at 128kbit/s with Lame was very close to 128 kbit/s ogg vorbis; at 96 kbit/s ogg was already losing to the 128 kbit/s mp3. So maybe size/quality ratio advantage of 10-20%, completely insignificant.Sure, with mp3 there was a lot of variation in sound quality betweenencoders. I still remember discovering lame - don't remember what I used before but that meant dropping from 256 kbit/s to 160 kbit/s for equal quality ("good enough for me"; 128 kbit/s was on wrong side of the edge of acceptable).So yeah, maybe opus or whatever is "much better", maybe "much" is 30% this time. But in the end that is irrelevant: if the original collection is in mp3, then any re-encoding is very likely to either significantly increase the file size or decrease the sound quality*, and the obvious lowest-risk and alsosimplestsolution is to just keep listening to the original files. Especially since mp3 is a simple, well-known format and all patent stuff is expired.*) there might be a theoretical possibility of lossless conversion between two different lossy formats if the encoding principle of the source format is a subset of the destination format, but probably such special encoder tool does not exist and re-encoding simply means decoding followed by encoding, which adds new artifacts over the existing.

author: mariush
author_rank: Super Contributor
timestamp: January 15, 2025, 08:29:28 pm
content: You have here information about how opus compares to other codecs :https://opus-codec.org/comparison/If you give a codec enough bitrate (ex 192 kbps vbr for mp3), it's getting harder to detect differences.Jpeg2000 suffered due to patents and issues with support for arithmetic coding ... way more processor usage for encoding and decoding for small quality improvements. Seehttps://en.wikipedia.org/wiki/JPEG_2000#Legal_status

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 15, 2025, 11:04:20 pm
content: Quote from: coromonadalix on January 15, 2025, 06:23:41 pmI don't understand what you mean here. FLAC is lossless. Whatever you feed it with will come out unmodified.But maybe it's your phrasing that was confusing and you meant converting MP3 to FLAC, then it's the MP3 format that makes a difference. Whether you'd decode MP3 to WAV or reencode to FLAC won't make a difference. It's lossless.I don't see a point in converting MP3 to FLAC whatsoever, unless this is for allowing decoding on much slower hardware, as FLAC decoding is lighter than MP3 decoding - but several people here already indicated that it wouldn't be an issue even on a Cortex M4. And, the gain in computing may be counterbalanced by the required increased data throughput from the storage device, which may then become a problem especially if the goal is to implement this on a slow MCU (slower than a typical Cortex M4). So, if that's the idea, think twice. MP3 compresses audio typically by a factor of 10 with decent quality, while FLAC is more like a factor of 2, so that's 5 times the required data throughput.OTOH, if that's for audio quality, I'd recommend going for FLAC for sure, again, it's lossless. As long as the source audio was uncompressed to begin with, otherwise it doesn't make sense. So, that means if you encode audio from CDs for instance. Also know that, while there isn't gigantic advertisement about it, many music editors now provide 24-bit audio directly in FLAC format, so if you buy music, you may as well buy that. I have absolutely zero affiliation with it, so just giving this link as an example:https://www.hdtracks.com

author: Siwastaja
author_rank: Super Contributor
timestamp: January 16, 2025, 07:06:37 am
content: Quote from: SiliconWizard on January 15, 2025, 11:04:20 pm... and storage device size. It would be a total fallacy to cost-optimize the part that is already smallest contributor to the cost, the CPUFor example, assuming that FLAC indeed is faster to decode:Flash memory to store a large library of flac files + MCU to decode them = 30 EUR + 0.50 EUR = 30.50 EURFlash memory to store a large library of mp3 files + a faster MCU to decode them = 10 EUR + 1.50 EUR = 11.50 EUR"Flash memory" in this context referring to e.g. an SD card.

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 16, 2025, 08:27:37 am
content: Yes. So re-encoding MP3 to FLAC doesn't make sense, but OTOH, supporting multiple formats is understandable, that makes your device more versatile, not requiring re-encoding existing audio material. And it all sounds pretty doable.In terms of MCU, if one wants something slightly more powerful (although just slightly) than a M4 while drawing very little current, I could alternatively suggest the STM32U5 that I'm working with at the moment. It's a Cortex-M33 running at up to 160 MHz, and draws only about 7.5 mA at that frequency. Crazy.

author: DavidAlfa
author_rank: Super Contributor
timestamp: January 16, 2025, 09:57:11 am
content: Flac vs 320 MP3 is only audible for dogs and bats ( 20-22KHz).Those old audiofools with wooden eardrums thinking they can tell the difference...

author: NiHaoMike
author_rank: Super Contributor
timestamp: January 18, 2025, 12:33:14 pm
content: Quote from: DavidAlfa on January 16, 2025, 09:57:11 amNot quite, even that view shows degradation in the spectrum above 16kHz or so. And the real differences in the lower frequencies are too small to tell with such a coarse view, although at 320kbps, it shouldn't be too much of a difference.