MP3 when the file ends ?

[Xenon02]

Hello !

I've acquired the DFPlayer for my STM32 Nucleo, and I've been wondering how it works a little bit (not that detailed), and I've read a bit how the mp3 file structure looked like, and I wondered how does the DFPlayer or any MP3 devices knows where the file starts and where the file ends ? If for example the file was mixed with other files that are not MP3 then DFPlayer has to know which files are which and where to start reading.

First of all I've tried to find this information and I found out that usually people are searching for the sync bytes that are usually the same and repeats in every frame so if it's in first frame and in the second frame etc it is then considered as mp3 file. So maybe the DFPlayer searches for the first sync byte or something like that, but how does he know how many frames have been sent in total ? If there is no EOF in mp3 file structure.

Second thing why I'm asking this is because when I want to change the music while the actual music is in the middle of playing he has to know how long is the music and skips the rest of the frames to go to next music and it's first frame. I wondered what is the algorythm of finding the mp3 file from all the data that is stored in the microSD card and from that he know how long is one music. I really wonder how it works.

 

[D.A.(Tony)Stewart]

DFPlayer Mini MP3 Player

doc.riot-os.org

 

[Xenon02]

DFPlayer Mini MP3 Player

doc.riot-os.org

This link gave me more questions than answers ;]

But as I read it, it seems that all the mp3 files are stored in folders and must be stored in folder.
So I assume that maybe the microcontroller first Starts with searching the folder with numbers or a folder with MP3 name on it. The it looks for the mp3 files ?

But how does it know what size are the specific mp3 file ? There is no EOF of the mp3 file. There are only frames and sometimes ID3 tags.

And another question is, where is the name of that file stored in mp3 file structure ? http://www.multiweb.cz/twoinches/mp3inside.htm here there is no info about file name or anything at the beginning.

Sorry and thank you for the link!

 

[Xenon02]

EDIT :

So I've read this site as well : https://doc.riot-os.org/group__drivers__dfplayer.html and I've learned something about FAT32. So I've wondered how it works. Because the MP3 structure format doesn't have : The name of the file, the amount of frames in 1 file, the end of file information. So does FAT32 adds the name of the file into the MP3 structure and adds the information of the size or rather the end of file information ?

For example if I've had : 001 super_music.mp3 then normally "001 super_music" file name isn't in mp3 structure, but rather the FAT32 adds this info ? If so can someone explain maybe how the DFPlayer knows when the title ends and when the normal data starts ? Because as I understand he tried to find a number in the title basing on the second link ?

I don't know, it's pretty confusing because how does the device know this is a title and not part of data from file like audio that happened to be 01 or something similar.

For example I had a File named 02/001 - super music.mp3.

So the structure of that looks like that <Folder name : 02 => in hexa also 02> <File name : 001=> in hexa 001> <mp3 - file structure> <File name with EOF> ?? Don't understand how the DFPlayer aquire the data from SD card when the SD card format is FAT32. I know that the DFPlayer can also work with only buttons without programming from the STM32 or other boards, so it has to somehow read data from SD card but I don't understand how. It uses some clusters and some dictionary table. Are they two different memory or something ? I don't understand how it works physically in memory when the device reads data. Like with mp3 structure it says which bits are for what and what frames are so each frame is a small piece of music, but FAT32 and how to access data from a specific file ?

https://www.cbtnuggets.com/blog/tec...xfat-vs-ntfs-file-system-formatting-explained - this is what I've read so far about FAT32, but I've seen other sites that explains the clusters or columns with data.

 

[KlausST]

Hi,

FAT32 is a file system. It describes how to store/find files. name, size and some other parameters. But it does not tell what information is stored inside a file and what´s the meaning of the data in the files.

MP3 is a file format for music.

***
Imagine you send a packet with goods to your friend.
* FAT32 is like the address label on the packet. It tells where the packet belongs to. How to find the distination.
* MP3 is what´s inside the box. Like 3x chocolate and 2x oranges.

Changing the FAT won´t change what´s inside the box. Like if you send the same packet to a different person it still will contain chocolate and oranges, you just need to update the addres label..

On the other hand you can change the things in the box while you don´t need to change the address label.

By reading the address label you don´t know what´s inside the box. (you still know the size, weight and where it belongs to, without opening it)
By reading an MP3 file content you don´t get informations about the file system.

--> So both informations are independent.

But for the goods to arrive at your friend you need to
* fill the box with the correct goods
* and you need to write the correct address on the label.

Klaus

 

[Xenon02]

FAT32 is a file system. It describes how to store/find files. name, size and some other parameters. But it does not tell what information is stored inside a file and what´s the meaning of the data in the files.

MP3 is a file format for music.

May I ask if I am correct or not ?
The SD card is just a memory card as I know, so all the data FAT32 labels, all the files folders etc, are stored in the same memory right ? If yes then how does the device (like DFPlayer) finds the labels of the FAT32 inside of SD card when in SD card there are tons of other information mixed with each other.

I just wonder how it works, is there a specific way to get a data.
Like I don't know how it searches for every label that has a number in it ? Like in the datasheet it says that the file needs to have 2 digit number and can have any name attached to that number for example : "02 - super song.mp3", so it looks for 02 name basing on the datasheet and ignores the rest of the name ? Even though the FAT32 sticks a label 02 - super song.mp3 and not only 02.

But okey comming back the let's say DFPlayer tries to find first 01 music but it doesn't exist so what is the callback from SD card ? That says nothing is here and search for more ? It would be weird to get a callback from SD Card about it. Why I mean weird because I only search for data and the data doesn't have any callback that something doesn't exist.

But what I imagined is that the mikrocontroler searches for first file in the SD Card and it is a label, and is the label a structure data that after the name (like 02 - super song.mp3) there is the rest of the data like size and which cluster is first etc ? If so then it reads all the data from that label and maybe there is an EOF in label data, after that the mikrocontroler starts to read now not the label but the first cluster which was pointed by the label ?

All of it is in the same memory so it kinda confuses me. I get the idea you've told me.
The FAT32 is a label that is attached to the file/folder it does not tell what the file has inside, it only shows direction and gives this file/folder a name to find it easier and to separate it from other data that is mixed in the memory.

The part I am confused is how it works physically, like how it finds the label when it is mixed with other data in the same memory or perhaps the SD Card has two different memory section or so to read the labels that are not mixed with the data (I don't know but maybe it doesn't make sense because it may run out of space for the labels when the memory itself still has space). I may have stupid ideas but I can't imagine it in a hardware way/physical with bits etc.

Thank you for the answer and sorry for any problems.

 

[KlausST]

Hi,

how does the device (like DFPlayer) finds the labels of the FAT32 inside of SD card

I´m no expert, so hopefully an expert corrects me if I´m wrong.

It does not matter whether CD, HDD, SSD, SD ... each has at the very beginning some identifier.
So it identifies which medium it is, how it is partitioned, what file system is used and where to find the FileAllocationTable (FAT).
It also tells whether there is a boot section ... and some other things.

Like: I´m an SD card with a total size of 1234MB, divided in two partitions of 1000MB and 230MB size, we use FAT32 and the FAT of partition 1 is at address 0x1234556.
... and so on.

Then the OS knows how to interprete the data. It uses the FAT32 driver for SDCards. (low level functions, which depends on hardware)

so you have memory araes for
* basics
* partitions
* FAT (within the partition)
* data(file) area

You may compare it with a book. It has a cover for basic informations, on the first page you find some author and printing informations, then maybe a prolog, an index, and then the pages and sections with the text. There even may be pictures.

So now the user can switch between partitions, can switch folders, can get basic file information, can create or open a file for access.
Commands, like:
open file "abcd.efg" to read content
are high level commands and are independent of hardware and are started by the application.
And if the according file not exists, then you will get a return code "file not found". The application has to handle the return codes.

The application is your MP3 decoder. It reads and understands the data of the MP3 file.
Neither the OS, nor the file system knows what an MP3 file is. They simply treat it as a bunch of bytes.
But the MP3 decoder can read file informations, like music title, compression, channel count, sampling rate ... and so on
And it knows where the music data is located, can address and read them.

You may surely find a complete OSI layer model for: SDCard -> FAT32 -> MP3...

********
You may find libraries for SDCard and FAT32 ...
The difference between OS and microcontroller is, then with an OS you have a clear deviation between the layers and the driver/interfaces, while in a microcontroller you usually don´t have this clear borders.

********

Klaus

 

[Xenon02]

Hello !

It does not matter whether CD, HDD, SSD, SD ... each has at the very beginning some identifier.
So it identifies which medium it is, how it is partitioned, what file system is used and where to find the FileAllocationTable (FAT).
It also tells whether there is a boot section ... and some other things.

Like: I´m an SD card with a total size of 1234MB, divided in two partitions of 1000MB and 230MB size, we use FAT32 and the FAT of partition 1 is at address 0x1234556.
... and so on.

Correct me if I'm wrong, as I understood about the partitions, for example the first partition is 1000MB and it contains the FAT32 which is stored in that 1000MB at address 0x1234556 etc.
So the partitions have the identifier I wonder if it's stored also in the same partition and if so it must know when is the start of partition and stop of the partition so there must be a name and a start partition at the beginning like in address 0x00000 or something like that ?

It's a bit confusing when I try to imagine it in numbers but I have to somehow understand it in numbers because that's how are they stored ;>

Then the OS knows how to interprete the data. It uses the FAT32 driver for SDCards. (low level functions, which depends on hardware)

so you have memory araes for
* basics
* partitions
* FAT (within the partition)
* data(file) area

You may compare it with a book. It has a cover for basic informations, on the first page you find some author and printing informations, then maybe a prolog, an index, and then the pages and sections with the text. There even may be pictures.

As I understand it is somehow coded and located. Although imagining how all this information are stored, confuses me. For example the partition information is stored in the same memory as all other data, so what if the partition name with the value like 0x0234232 can be confused with the data that can have the same value but it is not the partition information or so.

I grasp the overall idea but the how it is executed is confusing.
The labels, what are the labels pointing to, what are the cluster containing, and the content that is stored also in the same memory, all of it in one memory so to find the label in this whole bunch of information there must be some standards or something ... Because looking at value like : 0x0234232 can have label name, part of data in mp3 or other file, or partition name. So using the value like 0x0234232 seems off to me, so I wondered how it is executed.

So now the user can switch between partitions, can switch folders, can get basic file information, can create or open a file for access.
Commands, like:
open file "abcd.efg" to read content
are high level commands and are independent of hardware and are started by the application.
And if the according file not exists, then you will get a return code "file not found". The application has to handle the return codes.

The application is your MP3 decoder. It reads and understands the data of the MP3 file.
Neither the OS, nor the file system knows what an MP3 file is. They simply treat it as a bunch of bytes.
But the MP3 decoder can read file informations, like music title, compression, channel count, sampling rate ... and so on
And it knows where the music data is located, can address and read them.

You may surely find a complete OSI layer model for: SDCard -> FAT32 -> MP3...

To open file I need a label to that file and it is also stored in the same memory as the content of that file itself so it kinda mixes my mind how are they distinguished. I know that you've mentioned the partitions, but the name of that partition is also stored in the same memory as everything else. In other words I got confused with how the hardware/software is not mixing the values or knows where it is.

And the MP3 decoder requires some specific naming of the folders and files but it works somehow on it's own without codes from outside (like from STM32), just a single button can start the music. And it doesn't have OS I think because it has microcontroller.

And like you've said all of data is a bunch of bytes but somehow they distinguish one byte as a label and another byte as a data file. In which I understand a bit how files are listed and how the microcontroler can follow the path (like cluster 1 has the data returns to File alocation table and checks which cluster now from cluster nr 1 ). But now the thing is how it distinguish at the beggining when it tries to find the label first and it has to distinguish label from other bunch of bytes that are stored in the same memory.

I repeat many times same memory, but it indeed is mixing or maybe it is only for me. And I tried to understand how it distinguish data inside the memory when I have a microcontroler. I got confused and it's hard to explain what exactly (which is obvious it will be hard then for you to answer), so I tried to ask questions that could lead me to the answer, but it is also hard to imagine it in values of bytes, scanning the whole memory to find the partition name, then label name, etc. and all of it in one memory. Of course this information is not necessery to use the MP3 Player like DFPlayer but maybe understanding how this works especially how to find specific data in files/folders might be usefull ? I don't know but thank you for your patience.

Sorry for taking the time, thank you for the post, looking forward to see next post ;>

PS.
I know this is only theoretical stuff we are talking right now, but I really badly want to at least handle the concept or something because it is very interesting that one microcontroller is able to find a specific partition, specific lable, specific file not mixing then when they can have similar value at the beggining or something. I don't know if what I say makes any sense ;D

 

[KlausST]

Hi,

again, I´m no expert..

FAT32: is a file system A definiton how the files system is organized. Please understand it as a description, text.
FAT: is the FileAllocationTable. See it as index or an Excel table
these are two completely different things.

Please read documentation, Wikipedia, and/or watch videos.

****
Partition table.
For sure all is in the memory space of the SDCard.
But the partiton table has it´s place, where the OS can find it. I don´t know the exact location.
It´s really like with a book. You know the indx is usually at the beginning First second, third page... It´s surely not on page 65 of a 150 pages book.

****
At which location you can find what is clearly defined. If you need to know it down to the details you need to read the specifications.
I can only give coarse informations. I won´t read the documentation for you.
As said you will find detaield informatiion for each item (SSCard, FAT32, MP3)
Together they will have several 100 pages. Obvioulsy not possible to compress it into a forum post while explaining details.

****
I recommend to have a quick view through several documents. Then choose one that suits you most.
Read it. And if there still are questions, please post a link to the document and ask detailed questions b referring to the according document page/section.


Klaus

 

[Xenon02]

Hello !

FAT32: is a file system A definiton how the files system is organized. Please understand it as a description, text.
FAT: is the FileAllocationTable. See it as index or an Excel table
these are two completely different things.

Ah okey sorry will remember.

Partition table.
For sure all is in the memory space of the SDCard.
But the partiton table has it´s place, where the OS can find it. I don´t know the exact location.
It´s really like with a book. You know the indx is usually at the beginning First second, third page... It´s surely not on page 65 of a 150 pages book.

Perhaps you are right, although I still they can be mixed like here :

Of course it is just an example of FAT, but what I tried to say is that what if all of it is mixed. So if the indexes are at the beginning, then if I want to add new index then I have to shift the whole data to make a room at the beginning for new index because it could be mixed ect and how to find a specific thing in this mess.

I mean a believe you that it is probably somehow solved because OS know where is what but how microcontroller know what is where, How he know how many are there partitions, labels etc when only what I believe it receives is bunch of bytes and it scans all the data, or perhaps I am mistaken but I don't understand it. Sorry for going in circle if it looks like that.

PS.
Maybe I am again gravely wrong, but in this picture it shows that MYFILE1.TXT is poiting at cell and this cell points at different cell so where is the information that this txt holds ;D if only what the cell stores is another pointer.

At which location you can find what is clearly defined. If you need to know it down to the details you need to read the specifications.
I can only give coarse informations. I won´t read the documentation for you.
As said you will find detaield informatiion for each item (SSCard, FAT32, MP3)
Together they will have several 100 pages. Obvioulsy not possible to compress it into a forum post while explaining details.

Of course if it's to big then it could have make sense.

I understand that reading data from SD Card isn't that simple when it comes to finding specific bytes and interpreting them as labels or usable data or anything else.

I don't know where to find a specific information I want to find because usually when I type FAT structure or how it works I get a very simplified versions, do you have perhaps a recommendation or a website where I can read it ?

--- Updated Nov 29, 2023 ---

PS.

I also wanted to add that I also wanted to know how all of it works because if I had a chance to make my own MP3 module or anything that works with files from outside memory. I wanted to understand how to handle these stuff like how to program a processor or microprocessor or any controller to handle these files, but I wondered how it looks like how to program them in the way of where to find label in the memory, or where to find files (which the information is stored in the label), or any other stuff. It may sound easy but I found out that this is a bit complicated and all of the data is now mixed in my head and it's hard for me to say what is what at some point and how to find what writing a code ;D Like the labels, how to find it in the memory when writing code it is stored in the memory scattered gods know where and randomly into first possible free space.

 

[KlausST]

Hi,

if you search for "FAT structure" then you can´t expect specific information, because every (most?) file systems have a FAT, but every file system may have a different FAT.
FAT16 uses a FAT, FAT32 uses a different FAT

So if you want to read about the FAT of a FAT32 then look for "FAT32 specification" ... one chapter within this specification should tell about the FAT.

****
if you add a file, then you neet to add a new entry in the FAT and you need to stror the file´s data else where.
In the FAT you don´t necessarily to "insert" a new entry, just append it.
But deleted files are not really deleted, they are just marked as "unused". So in the FAT you have an entry "unused" and for sure you may use this for a new file.

I don´t tink that a FAT table is sorted. But the OS may create an index file that keeps the order of the files. There may be several index files. One maybe for the size, another for the name...

For example if you have four files:
chile.txt 1234 bytes
brazil.txt 3456 bytes
argentina.txt 2244 bytes
columbia.txt 3344 bytes

then the filename index could just be: 2, 1, 0, 3
and the size index could be: 0, 2, 3, 1

There are different strategies.
A super computer for a high count of files with low lifecycle will have a way different strategy than a (WORM) CD... where data can´t be overwritten (just marked as invalid)

Back to the SDCard: maybe the application expects the music files as one continous block. This means each music file is a complete block of data.
But file systems allow bigger files to be stored as many smaller pieces spread across the whole memory space.

Klaus

 

[Xenon02]

I don´t tink that a FAT table is sorted. But the OS may create an index file that keeps the order of the files. There may be several index files. One maybe for the size, another for the name...
For example if you have four files:
chile.txt

I don't know if it's cutted or intended to be like that ?

PS.

Like in this picture the label which are the root directory are scattered in random places same with file 1 file 2 and file 3. So maybe this shows what I tried to say


Also right now I am reading this : https://www.cs.fsu.edu/~cop4610t/assignments/project3/spec/fatspec.pdf and it says about the sectors but looking at the picture above I don't see those sectors how it works ;D But will still try to gain more from this spec.

Have a nice day !

 

[FvM]

File length info is in directory, not FAT.

I'm not sure which part of file handling you are doing in your code. Normally, embedded programmers are using a file system with standard open, close, read write, dir, find, etc. commands. If so, you don't need to care for internal structure of directory and FAT tables.

Of cause, these things aren't specific to MP3 file handling.

MP3 is a stream format. You can start to play somewhere in the middle of a file and play to the end or stop before. Info about song duration can be calculated but is also stored in ID3 tag. A MP3 player listing song info is displaying ID3 content.

For most file types, EOF is no mark in file content, it's generated by reading directory information.

 

[KlausST]

Hi,

Thanks FvM, you are absolutely correct.
That`s why I asked for an expert´s assistance.
I totally forgot about the directory table.

Again I want to recommend to read through some documents. At least this is what I´d do.
I wonder how chatGPT would answer.

Klaus

 

[betwixt]

In summary:
The Directory holds the file name, dates, size, permissions and a link to the files first entry in the FAT.
The FAT contains a list of links, each to a 'cluster' (one or more physical sectors or memory blocks). Each FAT entry corresponds to one cluster, if the file is too big to fit in one cluster, the FAT links to the next cluster where it's storage continues. The last FAT entry in a file's list contains an end of link marker.

Deleting a file simply marks it as deleted in the Directory and clears the first FAT entry so it and others in the chain (if present), can be used again. The actual data is still present until overwritten by a new file. Allocating space for new files is done by looking for cleared Directory entries and overwriting their FAT links with new data.

It is done this way to optimize storage, it allows large files to fill in the gaps left by deleted files, the file may occupy several clusters and they can be anywhere in/on the storage, the FAT provides the link to each part of the file. The downside is each Directory entry (file) must have an entry in the FAT and the FAT entry must point to at least one cluster. That means a file only one byte long requires a whole cluster to store it. Clusters can be one or more 'sectors', when files started to become so big that the FAT ran out of possible cluster numbers, the solution was to make the clusters themselves bigger, it allowed the FAT filing system to continue to be used but wasted more space if the file was small. FAT12, FAT16 and FAT32 are all the same thing, the number refers to the size (in bits) of the part of the FAT that points to the first or next cluster number. Later filing systems use different structures that work better than FAT but they still follow the same basic principle.

Answering the original question about MP3 file endings: the size is taken from the Directory entry for the mp3 file, they are not 'chained' one after the other with some distinguishing marker between them. If a single mp3 file contains several items, songs or whatever, their individual data is stored in "mp3 tags" which are part of the mp3 file structure, not the storage structure.

There - clear as mud!

Brian.

 

[Xenon02]

Hello !

File length info is in directory, not FAT.

I'm not sure which part of file handling you are doing in your code. Normally, embedded programmers are using a file system with standard open, close, read write, dir, find, etc. commands. If so, you don't need to care for internal structure of directory and FAT tables.

I've not been writing any code yet that would be so specific (I for now used only a simple ones for DFPlayer), but the curiosity was killing me on how and why it works :>
Comming back using standard open, close, read, write is like a premade functions like HAL, or other external functions, so they require a library, this library has to contain how to obtain a specific data in the memory when I write read txt file or something like that, so this is where I had a problem understanding how in code the person knew how to access a specific data, for example now typing read txt file it goes to the directory table but where is it ? Which specific ? The attempt look like that it searches for each byte in directory table and searches for "txt file" name what if part of that name "txt file" was part of another file ? Then it could mistakenly take different one.

So yea the backstage of how did they figure out to find this specific information in memory when some of that information like name of a file can be repeated. I don't know if what I said was understandable

For now I've read this : http://www.c-jump.com/CIS24/Slides/FAT/FAT.html
So I learned something about sectors like in this picture :

What I've interpreted it is that the whole bar is the whole memory, at the begging of the memory always at the beggining 0x00000 it stores the BIOS Parameter (BPB), so it's like a configuration, and it is fixes as I read it which ends after 512 bytes so the address can be I guess : 0x00200 or with more zeros at the beggining and I can or must contain the value in that cell 0xAAFF (2 bytes 0xAA and 0xFF) in 0x00200 cell (or rather the combination because it's 2 bytes)

So the next sector is FAT Area as I understand from this picture the Root Directory Starting location is in FAT Area, and the rest of Root directory is in the Data area ? So I assumed (because I have no confirmation), that Starting location of Root directory has only file name, and it points to another directory for other info like size etc. The rest of the FAT area is to point to another cluster in Data Area.

So basically Data area starts with a big offset because there is a fixed size for booting and for FAT area that are at the beggining. So when I want to find a text.txt file then I need to find a starting root directory in FAT Area then it points the rest of the Root directory in the Data area, from that I know the first cluster and other metadata, and I can access each cluster from one information which leads again to FAT area to show me where to go next. So the whole thing is to find the Root Directory I guess or the starting of it. So usually it works that I scan the whole FAT area to find this Root Directory starting point ? like the name "text.txt" ?

This link a bit confused me as well : http://elm-chan.org/docs/fat_e.html
Saying about FAT Entries to find as if they are scattered randomly as well so it adds to the confusion.


PS.
I also thought how the name would be stored if it can be of any length in the Root Directory, is it a fixed size ? like a name of a file is "I have a really cool name.txt" it is like 29 symbols which is 29 bytes in char, or even more longer text so each byte is 1 letter and if the root contains all this information then how long it can take to find a specific data like "file.txt". Because I understand it first searches for the name of the file in the directory and then it start looking for the cluster where it is stored when the program confirms it is the word it was looking for. Are they stored one after another the name in the FAT area section or are they mixed. I imagined it that if it finds the sequence "I" "h" "a" "v" etc. and if they are one after another stored then at the end is maybe a directory to the DATA area for more information of the root directory ?

Of cause, these things aren't specific to MP3 file handling.

MP3 is a stream format. You can start to play somewhere in the middle of a file and play to the end or stop before. Info about song duration can be calculated but is also stored in ID3 tag. A MP3 player listing song info is displaying ID3 content.

For most file types, EOF is no mark in file content, it's generated by reading directory information.

Oh when I read about mp3 files like in this link : http://www.multiweb.cz/twoinches/mp3inside.htm the TAGv2 (ID3) and the TAGv1 didn't contain the information of the song duration. So my best guess is that maybe in FAT32/FAT it is somehow described. And indeed it is in directory table.
Also it is good to know that EOF is more likely generated

Again I want to recommend to read through some documents. At least this is what I´d do.
I wonder how chatGPT would answer.

I got a bit lost in the documentary ;D
About ChatGPT I asked him about this, and he usually changes his mind about something all the time about this.

 

[FvM]

the TAGv2 (ID3) and the TAGv1 didn't contain the information of the song duration

There's an optional length field in ID3, but you are right, it's not used normally. Need to calculate length from (file - header and tag size) and bit rate. That's what apparently Windows file explorer does when displaying MP3 file details.

File systems role in this regard is telling you about file size.

 

[Xenon02]

There's an optional length field in ID3, but you are right, it's not used normally. Need to calculate length from (file - header and tag size) and bit rate. That's what apparently Windows file explorer does when displaying MP3 file details.

File systems role in this regard is telling you file size.

Yea so that's why I assumed that FAT32 format is here to help define the length of a song and to add the name of that file
Because name of the file is not stored as well in mp3 structure.

So I am reading how decoders are made and how do they read data from SDcards.

But the actual confusion when I read data sheets or documentation Is the directory table/root directory how it is accessed because the start is in FAT sector and the rest of that directory table is in Data sector. So I thought when I want to find text.txt or longer name file what is the key to find his root in FAT sector. Like I am searching for letter "t" in FAT sector, and the rest of letters and data are in Data sector. Like the algorithm to start looking for a specific file requires to find the starting point which is root table but a specific part that says about this file.

But I found out that this is more complex than I thought. Not conceptually because it is easy root says the starting point and length fat table points to next clusters to the end. But executing the algorithm seems hard. Like finding a specific data that is unique to that file. I don't know if you see my point of confusion.

 

[FvM]

Why are you worrying about file system internals? Do you want to rewrite the file system? If not, all necessary information is available through standard file functions.

 

[Xenon02]

Why are you worrying about file system internals? Do you want to rewrite the file system? If not, all necessary information is available through standard file functions.

I understand the concept but I don't understand how it is executed in a microcontroller. I don't know how to explain it. The microcontroller has to be programmed which means it needs a function an algorithm to read from data. This function must search the memory to find key data to find a specific file etc. I don:t know if what I say makes sense.

Because I don't understand it ;>
But okey I do mp3 decoder from scratch I plug in SD card and now I have to access the data inside of SD card and create functions that will help me controll the mp3 decoder. Now making a read command for mp3 decoder required a name of the file or folder. So I have to find the root directory and of that specific file. And then it reads or I don't know how microcontroller works in it or how it finds the root directory for purpose of finding the specific file to read it or write in it I don't know.

Plus the microcontroller as I know doesn't have the OS so I have to create an algorithm to find the root directory for a specific filer/folder etc. And I don't have pre made functions like in OS.

Or in other words, if there is any part that is unclear ? I may ask a wrong questions.