Accurate Directory / Folder List

Recently, I’ve been working with a MP3 player triggered with an UNO.

The MP3 support firmware will allow me to play any specific MP3 on the directory of the micro SD chip. The MP3s are accessed, not by name, but by position in the directory.

I find that I can not depend on Windozzz to give me an accurate list of the directory because it wants to help and sort them.

Will the DOS command dir /s /b > SD.txt produce a non sorted directory list?

Also, to get the MP3s on the micro SD chip in a specific order, do I move them there one at a time in the order I desire or is there a better way? I have some 250 MP3s to move, and maybe more on the next project.

About my first question and for anyone interested, the DOS command dir /s will give a directory listing as they are on the device. I tested by placing files on a freshly formatted SD chip where the file names were one, two, three, four, five, six, seven, eight, nine and ten. If they would have been sorted, they would not of appeared on the SD chip in the numerical order I placed them.

Doing the above for only 10 files wasn't all that laborious but I'll be working on 250 files. Even building a shell to do the move will take just as long.

Any ideas?

Seems like automating the move, what you call building a shell, would be easy and quick. A list of the files, add mv and “.”, go. I think it would win after 10 or 15 files. And could be redone again and again.

Or you could design a txt file to reside on the SD, it being some kind of redirection index, name versus file number in order kinda thing.

a7

since the name of the MP3s don't matter once they are on the device (DFPlayer mini?) why don't you call them 001.mp3 002.mp3 003.mp3 etc..

Copying them on the SD card "one at a time" would then be a simple enough script to write

alternatively - how are you going to remember the mapping between file number and file name? if you have an excel spreadsheet or something - build a macro to generate the script to copy files one by one.

Different computers add different hidden junk on SD cards. MacOS hides all sorts of junk on there that, when you open it with SD.open(), look just like .mp3 files and things. It will mess your ordering up completely in unpredictable ways. I fear that any solution using ordering of files is going to be a very long, rough journey for you.

-jim lee

yep - on macOS you would have to run a dot_clean /Volumes/<SDVolumeName> to get rid of all the . files

J-M-L:
since the name of the MP3s don't matter once they are on the device (DFPlayer mini?) why don't you call them 001.mp3 002.mp3 003.mp3 etc..

Copying them on the SD card "one at a time" would then be a simple enough script to write

alternatively - how are you going to remember the mapping between file number and file name? if you have an excel spreadsheet or something - build a macro to generate the script to copy files one by one.

Some great points! I wanted to keep the MP3 names so I would know what is what when maintaining them. But, building the directory would be difficult.

One workable solution is to merge the two ideas and put the position number just before the name. That way they will fall in line. That will work good till I wanted to insert one or more in some of the middle positions.
Issues like this is what makes life interesting.

J-M-L:
since the name of the MP3s don't matter once they are on the device (DFPlayer mini?) why don't you call them 001.mp3 002.mp3 003.mp3 etc.

I've seen some discussions that claimed if you put the files in a directory named mp3, and begin each filename with a four digit number, that the DFplayer will sort in numerical order instead of the order in which the files were written to the SD card. File extension does need to be .mp3 also.

We don’t know if it’s DFplayer though, was just a question

J-M-L:
yep - on macOS you would have to run a dot_clean /Volumes/<SDVolumeName> to get rid of all the . files

But that actually wont work on your precious UNO. The path names of the macOS file get longer than the available memory.

Been there, tried it. Not smart enough to solve the problem.

-jim lee

jimLee:
But that actually wont work on your precious UNO. The path names of the macOS file get longer than the available memory.

Not sure what you are saying.
I’ve done it or just open terminal, go to the volume and rm -rf ./.* to clean up timeMachine, finder and spotlight stuff.

Whart I'm saying is that The Arduino UNO can't delete them all. It can't reach all the way down the folder paths.

-jim lee

Ah yes, of course, you delete them on the Mac when you prepare the sd card (your arduino does not have access to the files anyway on a DFPlayer mini)

david_2018:
I've seen some discussions that claimed if you put the files in a directory named mp3, and begin each filename with a four digit number, that the DFplayer will sort in numerical order instead of the order in which the files were written to the SD card. File extension does need to be .mp3 also.

Yes, I have fund MP3 players that require the MP3 names to be numeric (with leading zeros) 00001.mp3, 00002.mp3.. More or fewer zeros and it won't work.
I've tested both. The one that I got doesn't have that restriction. Really makes it nicer because, I don't have to have extra documentation to know what is in any particular mp3 after a year or so.

About adding or removing files with the UNO, I have not done that. I use ether Linux or Windozz to do that task. I start with a freshly formatted SD chip and start adding the MP3s one at a time.

Also, if I ever need to insert a MP3 later, I'll have to rebuild the chip from the start.

Is there a utility that will sort and rebuild a directory? That would be nice. Then I could number the MP3s by 10s and to insert the file on the SD chip with a number between, like 15 or 25... then sort and rebuild the directory. Now, that would be nice.

billz1:
Is there a utility that will sort and rebuild a directory? That would be nice. Then I could number the MP3s by 10s and to insert the file on the SD chip with a number between, like 15 or 25... then sort and rebuild the directory. Now, that would be nice.

A little google searching found the fatsort utility, just checked and it is in the raspian repository for the Raspberry PI OS, and in the Ubuntu repository, so likely will be easy to try out on whatever linux system you are using.

From the man page (note the actual utility is all lower case) :

DESCRIPTION
FATSort sorts directory structures of FAT file systems. Many MP3 hard‐
ware players don't sort files automatically but play them in the order
they were transferred to the device. FATSort can help here.

I don't use my Raspberry PI as a desktop, but, I guess I can. That is a very good suggestion and I like it. I'll try.

Thanks david_2018

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.