Anyone know of a low cost hardware MP3 decoder?? - Page 1
Forum section: electronics / projects

author: nali
author_rank: Frequent Contributor
timestamp: May 08, 2020, 09:02:09 am
content: I know this is a dying breed but would like to find a decoder IC to let me play a stream from a MCU. This is a commercial product so needs to be "suitable for new designs". Interface can be SPI or I2S or even UART.VLSI have a series of devices but they are *expensive* and probably overkill as I just need a basic mono speech playback. Digikey shows a few other parts but I have the choice of "Discontinued", "Obsolete", or "Not for new designs"I do have a working solution playing WAV audio with a DAC but would like to move to MP3 if possible both to cut down file sizes, and the files originate as MP3 so I need to convert them (this is an online mobile device and the files are generated & downloaded on demand)

author: janoc
author_rank: Super Contributor
timestamp: May 08, 2020, 09:17:35 am
content: The Ogg Vorbis page has a list of vendors making hardware decoders:https://wiki.xiph.org/index.php?title=Vorbis_Hardware&mobileaction=toggle_view_desktopIt is Ogg format, not MP3, though some may decode MP3 too. Just keep in mind that you better budget big $$$ for the requisite patent licenses if you want to use MP3. MPEG consortium loves to sue companies for this.

author: nali
author_rank: Frequent Contributor
timestamp: May 08, 2020, 09:55:04 am
content: That's interesting and food for thought! I hadn't really considered that MPEG licencing was such a thing nowadays especially considering that open source has cracked it (ffmpeg etc) and the proliferation of dirt cheap MP3 players you can buy for less than the cost of a pizza. That probably explains the cost of the VLSI product.Actually OGG is an option... the files are actually text-to-speech from Amazon Polly which supports both so I'll look through the vendors on the page you linked, so thanks for that.

author: greenpossum
author_rank: Frequent Contributor
timestamp: May 08, 2020, 10:54:46 am
content: MP3 patents expired in 2017.

author: Someone
author_rank: Super Contributor
timestamp: May 08, 2020, 10:57:51 am
content: Quote from: nali on May 08, 2020, 09:55:04 amhttps://en.wikipedia.org/wiki/MP3#Licensing,_ownership,_and_legislationOpen source solutions are available and legal.

author: NiHaoMike
author_rank: Super Contributor
timestamp: May 08, 2020, 01:41:41 pm
content: How about a STM32? A quick search "stm32 mp3" shows many projects.

author: janoc
author_rank: Super Contributor
timestamp: May 08, 2020, 05:09:33 pm
content: Quote from: nali on May 08, 2020, 09:55:04 amMPEG isn't just MP3 format. The consortium is a cartel of various companies pooling patents to their technologies and then working them into standards that they release and license. That something has been cracked (actually MP3 hasn't been "cracked" - the format was published but you couldn't make an encoder or sell a decoder unless you paid the patent license fees) doesn't make the business model invalid.The VLSI cost is likely due to something else - it is an uber niche product these days because dedicated MP3 players have been practically eliminated by smartphones and for other application any reasonable ARM micro can decode something like Ogg Vorbis in real time even without floating point math (there is an integer only decoder). So the need for a dedicated decoder chip is pretty low.

author: Siwastaja
author_rank: Super Contributor
timestamp: May 08, 2020, 05:40:21 pm
content: Why can't you just software decode on any modern 32-bit mid-range MCU?MCUs capable of that cost some $2 and are the most used general-purpose types you would likely use anyway in a new design.If it's some text-to-speech thing, integrated 12-bit DAC of STM32, for example, would likely suffice for audio quality, making it really a single-chip solution with minimum cost.

author: TK
author_rank: Super Contributor
timestamp: May 08, 2020, 07:39:30 pm
content: If you need a chip solution, there some VLSI VS1011E chips listed on eBayDisclaimer: I am one of the sellers

author: amyk
author_rank: Super Contributor
timestamp: May 09, 2020, 03:04:41 am
content: Quote from: Siwastaja on May 08, 2020, 05:40:21 pmYou don't even need a 32-bit MCU, the countless cheap Chinese players around at the height of the MP3/"MP4" era were based around a Z80 or 8051 and a bit of hardware assistance (multiplier/MAC).

author: coppice
author_rank: Super Contributor
timestamp: May 09, 2020, 03:11:32 am
content: Quote from: amyk on May 09, 2020, 03:04:41 amThose players had an 8051 controlling the user interface, and a single chip MP3 decoder. The 8051 was not involved in the decoding at all.

author: boz
author_rank: Regular Contributor
timestamp: May 09, 2020, 06:49:56 am
content: WT2003S used to be a good bet but the supply seems to have dried up :-(I bought qty 10 for $3 a few years back for a car audio project and they were dead easy to work with, 16 pin SOIC, can interface to SD card and USB and requires only a few external caps and resistors and a micro on the serial port to control it. Sparkfun have the english datasheets and built some projects with them and lots of other projects on the interwebVS1053 would be my port of call today, bit more complex but lots of info out there.

author: nali
author_rank: Frequent Contributor
timestamp: May 10, 2020, 09:03:04 am
content: Thanks all, the answers in this thread have thrown up a few things to think about (which was the point of the post really), probably the most interesting is using a STM32 as it could do other things as a slave MCU.Just to clarify, I was kind of hoping to find a bolt-on single chip device for a few cents that I could just stream some data to.. this is the tail end of an ongoing design which is using a Nordic nRF52832 BLE MCU.@Siwastaja - I was originally using a 12bit DAC which worked OK, but I wasn't too happy with the audio, as the tail end of some sibilants was sounding a bit raspy, so I changed to 16bit. I suppose using a 2nd MCU I'd have plenty of GPIO to play with so could easily implement a R-2R DAC.

author: Siwastaja
author_rank: Super Contributor
timestamp: May 10, 2020, 09:16:12 am
content: Quote from: nali on May 10, 2020, 09:03:04 amNo no, not "slave MCU"; there are legitimate cases for a multi-mcu system, but I'm 99% sure this isn't one of them. Just do everything with one MCU/CPU, get rid of moving all that data around!Quote"built around an Arm® Cortex™-M4 CPU with floating point unit running at 64 MHz"While I can't guarantee this 100%, Ithinkit should be able to software decode just fine. Have you tried?Is there an option to upgrade to a more capable Nordic MCU, compatible with the existing code with minor changes?https://www.helixcommunity.org/projects/datatype/Mp3decis one option (just googled it), the performance numbers look like it should be able to do it. RAM seems a bit tight resource with this particular implementation, though.QuoteNo, R2R DAC is definitely much worse than an MCU-integrated 12-bit DAC. If the integrated 12-bitter isn't enough, use a proper audio DAC.12-bit audio has been succesfully used in recording and distribution, a classic C cassette is around equivalent 6-7 bits and just fine for speech, just a bit noisy.I'm 99% sure the raspiness of the sibilants was caused by something else than lack of bits.Did you have any filtration after the DAC? They can settle quite quickly, causing steps. A basic RC could do wonders.Unless the purpose of the speech is to be listened using audiophile gear, in well sound-insulated room, or high-quality headphones, for delivering "ear orgasms" of sorts, I bet an integrated 12-bit DAC is enough once you figure out what's degrading the result.

author: nali
author_rank: Frequent Contributor
timestamp: May 10, 2020, 09:51:10 am
content: Quote from: Siwastaja on May 10, 2020, 09:16:12 amYea you're probably right regarding the bits (my gut feeling agrees with you), I'll bear it in mind when I get to doing the audio. I can't recall if I had any filtering when I originally tried the audio, maybe just a simple RC. But as the audio data is 16 bit anyway I just decided to use a 16bit DAC.Out of interest, why is R2R so bad? I've no experience of them other than at college which was <ahem> years ago...The end application isn't audiophool, it's an aid for blind or visually impaired. So although I don't need HiFi I do need to maintain a reasonable clarity of audio.Edit: I'm not sure if the nRF will have the horsepower to decode audio as it's also running the BLE SoftDevice, also they don't have a huge amount of RAM to play with.

author: Siwastaja
author_rank: Super Contributor
timestamp: May 10, 2020, 10:13:20 am
content: To get any actual resolution (linearity) out of R2R, the resistor matching needs to be ridiculously good,andthe output driver impedance adds in series with the resistors, which is a random variable between about 10 to 50 ohms depending on chip, temperature, etc. This is easily many LSbs worth of error even in a 8-bit system already.So that's why DIY R2R usually provides up to about 5-6 bits, or maybe up to 8 if you do it properly.When you reduce the bit depth, you should definitely use dither when constructing the signals. Dither replaces a horribly-sounding quantization noise with a more pleasant white (or shaped, if you wish) noise. Shouldn't be too computationally intensive. If you still have a bit of extra resources available, you could oversample the output if your integrated DAC has excess data rate available, as well; i.e., generate multiple 12-bit samples from a single 16-bit sample.This being said, 12 bits might be enough even without dither. I guess the lack of output filter is the biggest problem. Even a very simple one (-6dB/oct RC) is better than nothing.

author: amyk
author_rank: Super Contributor
timestamp: May 11, 2020, 02:20:25 am
content: Quote from: coppice on May 09, 2020, 03:11:32 amThey have only two ICs, a NAND flash and the SoC itself. Those with an FM radio have one more IC for the radio.

author: coppice
author_rank: Super Contributor
timestamp: May 11, 2020, 02:42:19 am
content: Quote from: amyk on May 11, 2020, 02:20:25 amFully integrated SoCs came a bit later. Companies like Actions Semiconductors produced single chip solutions with an 8051 core for the UI, and a hardware MP3 decoder. Later they made chips with an ARM core and a hardware decoder. Finally they made devices with a more powerful ARM, and did the decoding in software. That made the solution more flexible as other codecs were needed. I am not aware of device that integrated an FM radio, but it wouldn't surprise me to find one. I expect they mostly used a separate chip.