Hello Wayne!
jwc1979 wrote: ↑Sat 2020-09-12 11:47
I found a strange question. The frame header of MP3 indicats the frame size is 144 bytes. but the actual size is bigger than that. for example, a mp3frame begin from the offset of 0x644, but the next frame is begin from 0x6f4. Could you please help to parse the attached files, why did this happen?
It looks to me that you have a buffering issue. Either you read too much, or too little from the VS1063a buffers, or your read counter has an issue. This issue was not there in your previous file test-new-02.mp3.
Here is the beginning of what my analysis tool tells about test-rtsp.mp3:
Code: Select all
@0x000000 = 0x982e5653 (0.00s): WARNING: NOT MP1 / MP2 / MP3
WARNING: Skipped 0x14 bytes
@0x000014 = 0xffe328c0 (0.00s):
MPEG 2.5 (0) Layer: 3 Sample rate 8000 Hz No CRC
Bitrate 2 -> 16 kbit/s Pad: 0 / normal frame Mono
Private bit 0 Copyright: Free Copy Emphasis: None
Bit reservoir used: 0
@0x0000a4 = 0xffe328c0 (0.00s):
@0x000134 = 0xffe328c0 (0.07s):
@0x0001c4 = 0xffe328c0 (0.14s):
@0x000254 = 0xffe328c0 (0.22s):
@0x0002e4 = 0xffe328c0 (0.29s):
@0x000374 = 0xffe328c0 (0.36s):
@0x000404 = 0xffe328c0 (0.43s):
@0x000494 = 0xffe328c0 (0.50s):
@0x000524 = 0xffe328c0 (0.58s):
@0x0005b4 = 0xffe328c0 (0.65s):
@0x000644 = 0xffe328c0 (0.72s):
@0x0006d4 = 0x302e5653 (0.79s): WARNING: NOT MP1 / MP2 / MP3
WARNING: Skipped 0x20 bytes
@0x0006f4 = 0xffe328c0 (0.79s):
@0x000784 = 0xffe328c0 (0.86s):
@0x000814 = 0xffe328c0 (0.94s):
@0x0008a4 = 0x656e6320 (1.01s): WARNING: NOT MP1 / MP2 / MP3
WARNING: Skipped 0x20 bytes
@0x0008c4 = 0xffe328c0 (1.01s):
@0x000954 = 0xffe328c0 (1.08s):
[... and so on, there were a total of 16 similar NOT MP1 / MP2 / MP3 + Skipped warnings ...]
Ok, let's see what happens exactly at the warning point you noted.
The first skip happens at the beginning of the file, but that is not a problem as it is clearly caused by us just jumping in at a random point in the middle of the stream. We find an MP3 header at 0x14, and from there we stay in sync for a while, which is good.
The issue begins right after the good header we see at 0x644. Although my analyzer doesn't notice it, there is another valid header already at 0x664, i.e. only 32 bytes later. The header at 0x6f4 is consistent with the header at 0x644 (0x6f4-0x664 = 144(dec)). So, something bad happens between 0x644 and 0x664.
There can be a few reasons for this:
1) Incorrect number of data read / written. This is a very common mistake: be careful that you have not mixed bytes with words. VS1063a tells how many 16-bit *words* you can read in SCI_HDAT1, then you need to write 2xSCI_HDAT1 *bytes* to your file.
2) VS1063a buffer overflow. If you read data too slowly, the 4 kilobyte buffer of VS1063a will overflow and result in unsync as seen here. It would also cause the audio to play with jumps, i.e. too fast. Because the bit-rate is so low (16 kbit/s), each jump would be about 2 seconds. Unfortunately I don't know the song that you have recorded, so I cannot really tell if this happens.
3) VS1063a buffer underslow. If you read too much data, the 4 kilobyte buffer of VS1063a will underflow, and result in unsyncs. It would lead to repeated audio. With 16 kbit/s bitrate each repeat would be about two seconds, which I think is not the case here.
Note that your previous example file test-new-02.mp3 did *not* have this issue, so please check what you have changed in your code after that.
Kind regards,
- Henrik
(PS. Plus, I still recommend activating the bit reservoir for better sound quality.)