> ## Content Index > Fetch the complete content index at: https://sreekars-journal.labvion.com/llms.txt > Use this file to discover other available public pages before exploring further. # Trying to understand the part between the sound and the model - URL: https://sreekars-journal.labvion.com/tm04-still-working-through-mfcc/ - Published: 2025-11-09T12:30:00.000Z - Updated: 2026-10-29T08:13:31.000Z - Description: The MFCC block has definite settings: 13 cepstral coefficients, 20 ms frames, a 20 ms stride, 32 filters and a 256-point FFT. Its output is a 650-value feature representation, while the audio window begins with 16,000 raw samples at 16 kHz. Those are different stages of the route from sound to - Author: Sreekar - Tags: TinyML, #Import 2026-10-29 10:08 The MFCC block has definite settings: 13 cepstral coefficients, 20 ms frames, a 20 ms stride, 32 filters and a 256-point FFT. Its output is a 650-value feature representation, while the audio window begins with 16,000 raw samples at 16 kHz. Those are different stages of the route from sound to a prediction. I want to understand the middle rather than let MFCC become the name of a box I skip. The feature settings say how audio is represented; they do not, by themselves, say how often the whole application predicts a word. The code first collects a complete input frame, then passes it into processing and classification. That makes the difference between a short analysis frame and the application's full window especially useful to keep in view. The raw recording is a sequence of sample values over time. At 16,000 samples per second, even a one-second clip contains a long list. A picture of the waveform can show when something gets louder or quieter. It doesn't immediately tell me how the sound's frequency content is changing, which is useful information for distinguishing speech sounds. MFCC features are a different representation of that recording. I'm trying to think of the process as a sequence of choices about what to keep. It doesn't attach the meaning ON to a sound by itself. It gives the classifier a structured set of features from which the learning stage can find patterns. ![MFCC configuration screenshot. Model-export settings corroborate the main feature-extraction parameters; this is not a live-classification accuracy result.](https://sreekars-journal.labvion.com/content/images/2026/10/IMG12.jpg) MFCC configuration screenshot. Model-export settings corroborate the main feature-extraction parameters; this is not a live-classification accuracy result. The first useful choice is to work with short sections. Speech changes through a word, so treating the entire second as one unchanging sound would miss the sequence inside it. A frame is a small piece used for analysis. The stride says how far along the recording the next frame begins. Those two settings describe related but different things. With both listed as 20 ms in this configuration, I need to read them as frame length and step size, not as a claim about the speed of the whole device. The application still has to collect its audio window, call processing and classify. A number in the feature settings doesn't prove that the live loop produces a prediction every 20 ms. I found that easy to blur in my head because all the values are times. One is about how the sound is divided for feature extraction. Another is how much audio a prediction uses. Another is the time the processor spends doing the work. They can all matter to responsiveness, but adding the same unit beside them doesn't make them interchangeable. The FFT is part of looking at frequency content rather than only the changing sample values. The filter bank then groups spectral information, with the mel scale involved in how those groups are arranged. Further processing produces the cepstral coefficients. I'm keeping that explanation fairly simple while I work through the stages. I don't need to pretend that knowing the full name means I can derive the entire method yet. The 32 filters and 13 coefficients aren't two labels for the same number of things. The coefficients are produced after further processing of the filtered information. That helps explain why the feature vector can be smaller than an earlier set of values. It also warns me against making an analogy too literal. I can't just call each coefficient one sound frequency and be done. A small timing calculation gives me another way to check my understanding. Twenty milliseconds at 16 kHz corresponds to 320 samples before considering the implementation's details. The configuration also has a 256-point FFT. I can't decide exactly how the software handles that relationship just by seeing the two values. The actual implementation matters; I shouldn't invent padding or truncation behaviour to make the numbers fit a quick explanation. That’s the point where I want to go from an introductory explanation back to the exported settings and code. An analogy is useful until I start asking what will happen to the actual buffer. Then I need the actual sequence. I would rather mark that gap than hide it under the phrase standard audio processing. The model has learned from features produced in a particular way. So the live device needs to use compatible sampling and processing. If I change the sample rate, scaling or feature settings on only one side, I may be giving the classifier something different from the kind of input it learned from. A model file isn't the whole pipeline on its own. This is why the microphone question keeps returning. Even if the feature code is unchanged, different recordings can produce different features. The laptop microphone and the INMP441 may not capture an identical version of the same word. That’s a possible source of difference to investigate, not something I can declare solved by choosing MFCC. I want to ask my mentor to follow one clip through this route with me. Not just name the blocks, but explain what kind of values appear after each step. Examples in the documentation can help me prepare a smaller question. They are less helpful if I accept a diagram as an answer to every implementation detail. What I like about this part is that it connects maths to a sound I recognise. I can hear a short command and still discover that there is a lot I haven't noticed about how it changes. The classifier's prediction is only the last visible piece of a much longer route. The feature count gives the two ends of the transformation a concrete connection. The application collects the complete audio buffer and wraps it as an Edge Impulse signal before raising the profiling pin. Processing then produces the representation used by the classifier. That means the cost of gathering the sound and the cost of turning it into features are separate parts of the route. A setting such as 20 ms belongs to that representation; it cannot replace a description of the program's full schedule. I'm not changing the settings just to have a new result today. I'm trying to understand what the current settings mean and where my explanation is still too broad. MFCC can stay on the diagram, but I don't want it to stay a box I skip over.