question about audio frame format of vs1063

Writing software that inputs and/or outputs audio and performs DSP algorithms such as filters, new codecs or audio effects.
jwc1979
User
Posts: 7
Joined: Tue 2020-09-08 2:56

Re: question about audio frame format of vs1063

Post by jwc1979 » Sat 2020-09-12 11:47

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
Attachments
test-rtsp.mp3
(46.76 KiB) Downloaded 11 times

User avatar
Henrik
VLSI Staff
Posts: 1174
Joined: Tue 2010-06-22 14:10

Re: question about audio frame format of vs1063

Post by Henrik » Mon 2020-09-14 11:27

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.)
Good signatures never die. They just fade away.

User avatar
Henrik
VLSI Staff
Posts: 1174
Joined: Tue 2010-06-22 14:10

Re: question about audio frame format of vs1063

Post by Henrik » Tue 2020-09-15 8:56

Hello Wayne!

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
It's always 0x20 (32) bytes. Perhaps there is something in there to help you find the issue.

Kind regards,
- Henrik
Good signatures never die. They just fade away.

jwc1979
User
Posts: 7
Joined: Tue 2020-09-08 2:56

Re: question about audio frame format of vs1063

Post by jwc1979 » Mon 2020-09-21 3:57

Hello Henrik
I'm sorry for reply so late.

Thank you for your suggestion. I will try it.

Kind regards.

Wayne.

Post Reply