Hello Henrik,
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?
thanks a lot.
kind regards,
Wayne
question about audio frame format of vs1063
Re: question about audio frame format of vs1063
- Attachments
-
- test-rtsp.mp3
- (46.76 KiB) Downloaded 221 times
Re: question about audio frame format of vs1063
Hello Wayne!
Here is the beginning of what my analysis tool tells about test-rtsp.mp3:
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.)
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.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?
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 ...]
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.)
Good signatures never die. They just fade away.
Re: question about audio frame format of vs1063
Hello Wayne!
Just one thing to add... After the initial Skipping Warning, all other warnings are of the same amount:
It's always 0x20 (32) bytes. Perhaps there is something in there to help you find the issue.
Kind regards,
- Henrik
Just one thing to add... After the initial Skipping Warning, all other warnings are of the same amount:
Code: Select all
@0x0006d4 = 0x302e5653 (0.79s): WARNING: NOT MP1 / MP2 / MP3
WARNING: Skipped 0x20 bytes
@0x0008a4 = 0x656e6320 (1.01s): WARNING: NOT MP1 / MP2 / MP3
WARNING: Skipped 0x20 bytes
@0x001fd4 = 0x30302e56 (3.96s): WARNING: NOT MP1 / MP2 / MP3
WARNING: Skipped 0x20 bytes
[... etc etc, until the last message ...]
@0x00af14 = 0x2e56534d (22.10s): WARNING: NOT MP1 / MP2 / MP3
WARNING: Skipped 0x20 bytes
Size: 46.8 KiB / 0.0 MiB
Format: MP3
Conf: 1 channels @ 8000 Hz
Frames: 329
Time: 0:23.6
ChMode: Mono 100.0%
Bitrate: 16.2 kbit/s CBR (16 kbit/s, 0.0% padding frames)
16kb/s: 329 *****************************************************************
BitResv: Not used
Kind regards,
- Henrik
Good signatures never die. They just fade away.
Re: question about audio frame format of vs1063
Hello Henrik
I'm sorry for reply so late.
Thank you for your suggestion. I will try it.
Kind regards.
Wayne.
I'm sorry for reply so late.
Thank you for your suggestion. I will try it.
Kind regards.
Wayne.