SPE035 Serial MP3 - Playing short files

SGraham

New Member
Thank you for a very interesting and informative thread.
I was interested in building a talking volt meter/probe, using a PICAXE and the DF Player. I would be interested in speaking 1,000 voltage levels. To save on the number files on the SD card I would make each word a separate file. I.E. +23.74 would require playing six files, closely after one another. Most of these word file are less than 2 seconds long. I read somewhere that short sound files are a problem is that because of the busy line lag? or is it something else?
 

hippy

Technical Support
Staff member
I moved the post to its own thread; it's better to start a new thread than add to an existing unrelated one.

I do recall some saying they had issues playing short files but I do not know what the problem may have been there or which playback product they were using. I did have a speaking counter program working which used the same technique of speaking single digits but also cannot remember which playback product that was for.

I would have thought there would be some way round it even if there were some issues.
 

tmfkam

Senior Member
In my experience of the (superb) SPE035, the start time of the files can vary. This could be down to the location of the files on the storage device, the file structure used, or the storage device itself. This leads to a conundrum when testing the busy flag to see whether a file has started to play, whether it is still being loaded, or whether it has been played and has now stopped.

The busy flag often fleetingly indicates that it is 'playing' when it is looking for a file, then indicates 'stop', before locating and truly playing the file. This should be considered when checking if a file has begun to play.

For work, I have used these for sound playback in a commercial design. Only last week when trying one with a short sound 'loop' I found that it wasn't playing one (just one, of ten) of the files, just silence. This required me to extend the 'start' delay by a few milliseconds. I am reasonably sure this was down to a slow USB memory stick I was using. The result was that I was trying to load the file and play it then attempting to repeat it before it had actually begun to play.

Finally. Do be aware that if the storage is not formatted as FAT, it may not be recognised. I made this mistake also recently and was checking, double checking and re-checking my soldering when the light finally dawned...
 

AndyGadget

Senior Member
I've just been experimenting with the DF mini module that the SPE035 incorporates and was looking for minimal pauses in playback.
What I've found is that using the $03 command to play the file directly from the FAT pointer is much quicker than specifying a track and/or folder number (command $0F, $12 or $14). Presumably the module takes time to resolve the folder / track notation to the file index.
This does take a bit more planning and you will need a utility such as the aptly named 'FAT sorter' to arrange your card in the order you want.

The SPE035 PDF states that the limit for this method is 255 files, but looking at the module manual the limit is 2999 ($BB7) files. This is possibly because the SPE035 sheet assumes a FAT card format which ISTR had a 256 file limit in the root directory. I'm using 755 files on a FAT32 formatted SD card and it works fine.

Anyone for a Picaxe Mellotron :)
 

tmfkam

Senior Member
I've just been experimenting with the DF mini module that the SPE035 incorporates and was looking for minimal pauses in playback.
What I've found is that using the $03 command to play the file directly from the FAT pointer is much quicker than specifying a track and/or folder number (command $0F, $12 or $14). Presumably the module takes time to resolve the folder / track notation to the file index.
This does take a bit more planning and you will need a utility such as the aptly named 'FAT sorter' to arrange your card in the order you want.

The SPE035 PDF states that the limit for this method is 255 files, but looking at the module manual the limit is 2999 ($BB7) files. This is possibly because the SPE035 sheet assumes a FAT card format which ISTR had a 256 file limit in the root directory. I'm using 755 files on a FAT32 formatted SD card and it works fine.

Anyone for a Picaxe Mellotron :)
That's useful information, thanks. Sadly, our customers want to be able to update their own 'music'. It is tricky enough getting across the \01\001.mp3 folder\file naming convention, without dealing with organising them on the allocation table too.

I originally designed a prototype using a VLSI module, this had similar requirements (aligning the tracks on the disk by adding them in a specific order, as well as naming them 'correctly') for certain implementations, it was one of the things that caused me to change over to the SPE035. The biggie though was that I had to re-draw the module circuit to be able to add USB capability. The SPE035 has this capability built in which was much easier for me. Decision made in favour of the SPE035.
 
Last edited:

premelec

Senior Member
I don't know if it would help but I have used a program - MP3tag - which arranges sequences of files to play... perhaps no faster than usual - anyhow good luck with the project...
 

SGraham

New Member
Thank you all for your help. I will have to look into SPE035. Most of the speech synthesizers sound terrible, so I was hoping this might make human interface when a limited vocabulary was required.
I just completed my electrical regulations refresher course. It started of with a video showing the gruesome results of electricians working on live switchboards (which is a no No.) when runaway mains arks happens. I noticed that many of these accidents happen when a meter probe slips. The electricians on the course , who do that sort of work all seem to have lashed up some way of having one probe secured to their meter. This is so they do not have to look away from where they are sticking the probe to see the reading. We have all had a probe slip, while looking at the reading on the meter, maybe we have been lucky and with voltages we are using it is not a risk to us, only the equipment. As I see it talking equipment will replace digital displays soon.
 

hippy

Technical Support
Staff member
As I see it talking equipment will replace digital displays soon.
I am not so sure. Integrated chips for good quality speech output have been possible for some time and would probably be near zero cost when used in quantity but there seems to be no rush towards that.

I am not doubting usefulness of speech in specific cases but there seems little desire for it generally.

Perhaps it is a chicken and egg situation; very little has it so people don't appreciate its benefits but I suspect it's not always as useful as may be imagined. It takes time for speech to be output and therefore extends the time for taking something in, and for voltage readings those can be continually varying even if only slightly. Perhaps there's an issue of information overload which a visual reading does not have?

Even expensive meters for doing the job described don't have it and one would have thought the big manufacturers would have considered it.

It's definitely something worth doing because there's no better way to discover the pro's and con's.
 

techElder

Well-known member
As I see it talking equipment will replace digital displays soon.
Well, +1 for your futuristic outlook, but try conversing with a crowd about the "talking" telephone menus we're all greeted with when calling the phone company. That'll curl your earlobes. :D

Also, try to imagine listening to a voltage ramp adjustment via speech, a room full of technicians working on separate projects or the batteries needed to drive an audio system in a room full of contractors working on their own trades. (The freaking boom boxes alone will drive you crazy on construction sites here in the USA! :D)
 

premelec

Senior Member
For low vision ability people voice helps... considering many dialects and inflections there is a lot of room for error - Being a telegrapher [Morse] I have made a number of units which report numbers in Morse that work well. I have an old pocket calculator that reports numbers as musical notes... whatever works reliably I'm for it! [no I don't like my cell touch screen]. :geek: That said my cell interprets common voice input very well so I use that... :)
 
Last edited:

AndyGadget

Senior Member
As an addendum to my comments above, resampling at a lower rate makes a small but noticable difference to the delay before playing.
Dropping my samples from 44.1KHz to 12Khz reduced a typical file size from 670KB to 180Kb. My samples are around 12 seconds long.
For 2 seconds of speech you could resample at 6Khz and probably reduce delay further.
I'll try it at the weekend and post results here.
 

hippy

Technical Support
Staff member
If the total number of tracks supported is more than 255, and I also believe it is, it could be possible to have a file per possible reading.

Then one only has to worry about start-up latency rather than any delays between the words.

One could achieve that by using a text to speech program to speak each reading or concatenating individual words and gaps into .WAV files, converted to .MP3 if desired.

I can appreciate the desire to reduce the number of tracks on the card but number of tracks and their size doesn't really matter once they are on there.
 

SGraham

New Member
Thanks for all the input. Clearly speech has its limitations but in other applications it has advantages. I think it would be good if it was as easy to make an item talk it information as it is to display it on a numerical display. I started out with that assumption that short sound bites (word.) would be as easy to play/sequence. I was wrong.
AndyGadget referred to the SPE035 information, from what I can see of the code shown is incorporating items from blockly. I could be wrong about the lines "SerTxd("Starting", CR,LF )" and "SerTxd(Select microSD Card", CR, LF )" but the text in red are not standard command nor have they been declared. Could you let us know what commands can be sent to the DF player and which can't to get this direct mode?
 

hippy

Technical Support
Staff member
I could be wrong about the lines "SerTxd("Starting", CR,LF )" and "SerTxd(Select microSD Card", CR, LF )" but the text in red are not standard command nor have they been declared.
Those are just 'reporting commands'. They show on the terminal to let the programmer know what the program is doing, where the program has got to when running. They don't actually affect the MP3 player itself.

The "cmd = $09 : arg = $0002 : Gosub Send" type lines are the ones which specify the commands which are sent to the player module.

Could you let us know what commands can be sent to the DF player and which can't to get this direct mode?
The commands are listed on page 19 of the SPE035 PDF. The two commands you are probably most interested in are -

0F ff tt Play from folder ff=01-63, track tt=01-FF
14 ft tt Play from folder f=1-F, track ttt=001-3E7

The first allows 63 folders of 255 tracks, the seconds allows 15 folders of 999 tracks. If you have 1000 tracks it would probably make sense to have 10 folders of 100 tracks -

Code:
cmd     = $0F
arg.msb = 1 to 10  ; Folder
arg.lsb = 0 to 99  ; Track
Gosub Send
 

SGraham

New Member
Thank you hippy for putting me right, I realized shortly after I had posted that those had to be going somewhere else.
Also thank you for clarifying which commands put the system into the slower folder mode. I only need access to 26 words. I saw somewhere someone said that deleting a (track?) from the SD card did not stop the DF played it! I suspect that deleting the track may remove it from the menu system, but in this simple and faster access all the tracks are still their and in there original order and position. I may well be getting it wrong again.
 

hippy

Technical Support
Staff member
I saw somewhere someone said that deleting a (track?) from the SD card did not stop the DF played it! I suspect that deleting the track may remove it from the menu system, but in this simple and faster access all the tracks are still their and in there original order and position.
I believe that could be right. The way files are deleted on a FAT file system is to simply mark the entry as no longer used, so the file is still there and can be undeleted if undeletion is done quickly enough after deleting.

When the mark is seen the file is not listed by Explorer or DIR so it is as if it has been permanently deleted. It could be that the MP3 player does not honour the mark in the same way, still plays the file even though it has been deleted. Or it could be the case when one asks to play the Nth file in the directory rather than to play a file by name or number.

The way round that is to keep a directory on the PC which contains the files wanted on the SD Card, add and delete in that directory, and then copy those to a newly formatted card which will ensure only those not deleted are copied to the card. Copying one at a time ensures they appear on the card and play in the order copied.

I recall there are programs which can do the copying or sort the directory into the right order after copying which saves having to copy one at a time.

It is all a bit of a pain, but should not need to be done that often.
 
Top