Advice Wanted: MP3 player for Arduino MEGA

George: You should be looking into the DFPlayer mini MP3 player module. There seem to be plenty of videos and adequate documentation on this. Take a look.

@Consolidated Leo posted:

George: You should be looking into the DFPlayer mini MP3 player module. There seem to be plenty of videos and adequate documentation on this. Take a look.

Hi Leo!  Thanks for responding.  I'm looking at this listing and don't understand something - why are there 3 of them?

https://www.amazon.com/UMLIFE-...&sr=8-3&th=1

George

Hey George,

It says at the bottom of the description that you get three of the modules.

John Cody

@bigboy25 posted:

Hey George,

It says at the bottom of the description that you get three of the modules.

John Cody

Yeah, I know.  I was just wondering why.

Can anybody recommend speakers for this item?

George

George: You don't need to buy three; it's a buying option.

Here's a link to a datasheet that will give you some idea what this module can do:

MicrosoftWord - MP3－TF－16P V1.0_en.doc (picaxe.com)

There's a lot there to think about but mostly I think you should skim through this document to see that it will meet your requirements.

Next you should just watch some YouTube videos on this device being used with an Arduino. Here are a couple of links:

DfPlayer Mini Module - Play MP3 Files With an Arduino (Step-by-step Guide) - YouTube

#40 Let the music play! Arduino based MP3 Player for music (or announcements) - YouTube

Arduino-Based MP3 Player via DFPlayer Mini Module - YouTube

Since you'll be using the Arduino Mega 2560, you can use one of the alternate hardware serial ports to communicate with the module. You won't need buttons since the commands can be issued from the Arduino. I believe the library that is used with this is from RFRobot and is most likely available for download from the IDE.

I have also used the Spark Fun MP3 trigger board for my Lost in Space robot build and I also use it with Arduino Mega.  Available on Amazon.

I looked at the DFPlayer, but I like the BY8001-16P MP3 Player Module better.  It also had better documentation, at least I though so at the time.  Also, the DFPlayer has a flaky SD card holder, the BY8001-16P has a much nicer spring eject mechanism.

BY8001-16P MP3 Player Module.pdf

All,

Thanks for responding.  I had been looking at one of those YouTube videos, but will pursue them all.

George

George: @gunrunnerjohn speaks with the voice of experience. I would go with his recommendation for the upgraded module; the BY8001-16P. It looks as though it is compatible with the DFplayer mini as far as I can tell. You can't go wrong taking John's advice.

128GB?  That represents thousands of MP3 songs or weeks/months of 24/7 audio!  Curious how a train layout animation uses so much content.

One thing about MP3 players is they can have a noticeable hiccup when transitioning from one .MP3 file to the next - has to do with the compression algorithm and how the software for the player was designed (or not) to transition between compressed files. This may or may not be relevant to your animation.

That said, if you have 128 GB of storage, you might consider storing the content in an uncompressed, or less compressed format such as .WAV.  In which case you wouldn't need an MP3 player module as the Arduino itself could decode the audio and make it easier to seamlessly transition from one audio clip to the next.

Are you taking advantage of stereo?  MP3 has the useful feature of storing the left and right audio tracks with 100% separation.  So, for example, if you animation really has two sources of sound, you can independently store one on the left track and the other on the right track and they will not spill over into the other channel.  This can be useful in an animation since you can project motion by having the sound sweep from one speaker to the other.

If your audio is mono, you can use the spare track to store the animation commands which would be exactly synchronized to the audio.  This is how Disneyland revolutionized animatronics.  For example, you could store a sequence of touch-tones that would control, say, motors and lights. It's been a few years but I can probably dig up OGR threads on animation that demonstrate this if there's interest.

The BY8001-16P module will decode stereo MP3 but it has only 1 audio amplifier.  You have access to the two electrical signals for Left and Right but these are not low-level signals so you would need to provide external amplification.

@stan2004 posted:

The BY8001-16P module will decode stereo MP3 but it has only 1 audio amplifier.  You have access to the two electrical signals for Left and Right but these are not low-level signals so you would need to provide external amplification.

Did you mean to say they are a low-level signal?  I've never used these outputs, but they appear to be high impedance audio outputs directly from the decode DACs.

OK, so perhaps I should discuss the audio requirements of the animation in more detail.

I am building an Open Hearth (OH) steel mill in which there are 4 furnaces.  Each furnace will be modeling 1-3 different operations within the OH process.  I haven't determined the exact soundtrack for each operation, but I anticipate a variety of sound effects ("whooshing", "roaring", "hissing", mechanical clanking, etc.).  There will also be some old fashion sirens blaring when overhead cranes are involved.  I will be using a sound editing program to overlay these sounds (as appropriate) into a single sound file.

To make things even more interesting, there are a number of time frames to consider.  Each operation's soundtrack will have several versions based on the time compression involved.  For example, a Meltdown operation would last 90 seconds, 180 seconds, 450 seconds, or 900 seconds depending upon the time compression value selected.  I thought the easiest thing to do would be to create recording files of those lengths and have the correct one selected programmatically.

These are the reasons why a large storage capacity and file structure are important features of any player I select.

Thanks,

George

Well, even with WAV files, a 128GB FLASH card would provide a bunch of play time!  A 24 bit, 48KHz WAV file would be about  1 GB per hour.   That means you get 128 hours on a 128GB FLASH card, surely way more than you need, even assuming a bunch of duplicate sound clips.

A bigger question is, if you have four furnaces all running, are you going to have four sound boards, one for each?

@gunrunnerjohn posted:

Did you mean to say they are a low-level signal? ...

Yes. Corrected in my original post.  Thanks.

@gunrunnerjohn posted:

Well, even with WAV files, a 128GB FLASH card would provide a bunch of play time!  A 24 bit, 48KHz WAV file would be about  1 GB per hour.   That means you get 128 hours on a 128GB FLASH card, surely way more than you need, even assuming a bunch of duplicate sound clips.

A bigger question is, if you have four furnaces all running, are you going to have four sound boards, one for each?

That's a slightly more complicated question than it would seem. 

The answer is a qualified "no".  I'm thinking all furnaces will be lit from within at a minimum.  As each is highlighted (by having the overhead lighting turn on) and demonstrates its operations, other accessories specific to it (including sound) will be activated.  That's the current hallucination, er idea.

But with an Arduino MEGA 2560 powering the whole affair, there are plenty of pins for additional MP3 players, perhaps 1 per furnace.

George

@stan2004 posted:

128GB?  That represents thousands of MP3 songs or weeks/months of 24/7 audio!  Curious how a train layout animation uses so much content.

One thing about MP3 players is they can have a noticeable hiccup when transitioning from one .MP3 file to the next - has to do with the compression algorithm and how the software for the player was designed (or not) to transition between compressed files. This may or may not be relevant to your animation.

That said, if you have 128 GB of storage, you might consider storing the content in an uncompressed, or less compressed format such as .WAV.  In which case you wouldn't need an MP3 player module as the Arduino itself could decode the audio and make it easier to seamlessly transition from one audio clip to the next.

Are you taking advantage of stereo?  MP3 has the useful feature of storing the left and right audio tracks with 100% separation.  So, for example, if you animation really has two sources of sound, you can independently store one on the left track and the other on the right track and they will not spill over into the other channel.  This can be useful in an animation since you can project motion by having the sound sweep from one speaker to the other.

If your audio is mono, you can use the spare track to store the animation commands which would be exactly synchronized to the audio.  This is how Disneyland revolutionized animatronics.  For example, you could store a sequence of touch-tones that would control, say, motors and lights. It's been a few years but I can probably dig up OGR threads on animation that demonstrate this if there's interest.

The BY8001-16P module will decode stereo MP3 but it has only 1 audio amplifier.  You have access to the two electrical signals for Left and Right but these are not low-level signals so you would need to provide external amplification.

Stan,

I think the creation of an individual sound file of appropriate length eliminates the transition "bump" you spoke of.

So you are suggesting storing the sound files as .WAV on the MP3 players SD card, correct?  That sounds like a great idea!

Thanks,

George

@G3750 posted:

Stan,

I think the creation of an individual sound file of appropriate length eliminates the transition "bump" you spoke of.

So you are suggesting storing the sound files as .WAV on the MP3 players SD card, correct?  That sounds like a great idea!

Correct, the WAV file being uncompressed eliminates the decoding pause you frequently get with MP3 files.

I've tried this on my MP3 Board that uses the BY8001-16P module, it pretty much eliminates the pause between different tracks.

@G3750 posted:

...

So you are suggesting storing the sound files as .WAV on the MP3 players SD card, correct?  That sounds like a great idea!

A little more info on the transition bump or hiccup is in this OGR thread where GRJ and I are mud wrestling the fine details of the module in the context of train applications.

It's documented somewhere, but IIRC the BY8001 module can only access a finite number of audio files.  So you're basically telling it to play audio file #1, #2, etc..  The module hides the "file system" from you.  The Arduino has absolutely NO access to the audio files themselves. This can be a plus or a minus depending on your point of view.

Depending on your comfort level mucking with Operating System (file management) software - I'm sure there are Arduino libraries to deal with SD cards - you could simply get an Arduino SD card module where the Arduino directly talks to the SD card over, say, the SPI port.  If you store files in .WAV format, there is virtually 0 effort (MIPs expended) to grab audio samples from memory.

@stan2004 posted:

A little more info on the transition bump or hiccup is in this OGR thread where GRJ and I are mud wrestling the fine details of the module in the context of train applications.

It's documented somewhere, but IIRC the BY8001 module can only access a finite number of audio files.  So you're basically telling it to play audio file #1, #2, etc..  The module hides the "file system" from you.  The Arduino has absolutely NO access to the audio files themselves. This can be a plus or a minus depending on your point of view.

Depending on your comfort level mucking with Operating System (file management) software - I'm sure there are Arduino libraries to deal with SD cards - you could simply get an Arduino SD card module where the Arduino directly talks to the SD card over, say, the SPI port.  If you store files in .WAV format, there is virtually 0 effort (MIPs expended) to grab audio samples from memory.

I have some familiarity with operating systems (although it's been ages ago) but I find that "easier is better".  Regardless, I will investigate all the options.  Apparently (if the Arduino experience has proven anything), you can teach an old dog new tricks.

Thank you!

George