MP3Model/MP3 Codec file seeking behaviour

Discussion about writing software for VS1005 and the VSOS Operating System. Also posts about VS1005-related hardware design and device drivers should be posted here.
alex_t
User
Posts: 5
Joined: Sun 2019-04-07 12:50

MP3Model/MP3 Codec file seeking behaviour

Post by alex_t » Sun 2019-04-07 13:00

Hi,

I've been tasked with supporting one of our company's audio player products, which is based on VLSI's VS1005 chip, and we're currently on VSOS 3.33.

We've noticed that for larger MP3 files (of the order of 20 megabytes, roughly 25 minutes playtime on average), rewind operations take an awfully long time (using the CodecServices .goTo() method) compared to fast forwarding using the same method. At first I figured there was a problem with our audio player application but I've been able to reproduce the same behaviour using a slightly modified version of Panu's classic player on a developer board, in which I issue UIMSG_U32_PLAY_TIME_SECONDS messages to the MP3Model as opposed to calling .goTo() directly.

As the codecs are closed source it's hard for me to figure out why file seeking in the reverse direction is taking longer than I'd expect (anywhere from three to ten seconds for a 30 second backwards seek, for example). Would it be possible to shed some light on why this is happening, or if it's a known issue that has been addressed in a later version of VSOS?

Any help you could provide would be greatly appreciated.

Best regards,

Alex.

User avatar
Panu
VLSI Staff. Currently on holiday.
Posts: 2698
Joined: Tue 2010-06-22 13:43

Re: MP3Model/MP3 Codec file seeking behaviour

Post by Panu » Mon 2019-04-08 9:09

Hi!

I think It happens because MP3 is a streaming format, e.g. it doesn't have any notion of sample counting. MP3 was originally designed for satellite radio broadcasting, not for a file format so the file doesn't have any sample counters or index. When the codec seeks to a position, it needs to decode the file forwards from a point. If you seek forwards, it will decode from current position forwards until it finds the correct position. If you seek backwards, it will decode from the beginning of a file until it finds the correct position. Decoder routines for other formats than MP3, if they have indexes or sample counters, are able to do that more efficiently.

With MP3 it's technically possible to seek to a random point in the file to find an approximate location. The decoder design engineers could be able to help you to do it reliably. With earlier chips it was done by putting the MP3 decoder into resync mode and seeking to a (random) position inside the file. I have not done that in VS1005 personally, though.

-Panu
Info: Line In and Line Out, VS1000 User interface, Overlay howto, Latest VSIDE, MCU Howto, Youtube
Panu-Kristian Poiksalo, VLSI Solution Oy

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

Re: MP3Model/MP3 Codec file seeking behaviour

Post by Henrik » Mon 2019-04-08 14:29

Hello Alex!

I will elaborate slightly on what Panu wrote.

As Panu said, Mp3 files don't have time indexes, so if you are playing at for example 1:29 (1 minute 29 seconds) and you want to jump to e.g. 2:00, there is no way to be sure where in the file the exact destination point is. So the only way to be sure is to decode 4-byte MP3 headers (MP3 headers occur approx. 38 times a second if the file is at 44.1 kHz) and count how many samples / seconds have passed until you get to the destination point in the file. This is not much of a problem when fast forwarding: if you fast forward half a minute, the decoder needs to skip approx. 1150 MP3 headers, which is generally quick to implement if the media is fast like an SD card. But when you rewind, the decoder starts from the beginning of the file and decodes all MP3 headers up to the destination point. So, if you seek from e.g. 25:30 to 25:00, that requires traversing the whole file from the very beginning, through as much as almost 60,000 MP3 headers, and megabytes of data, which unfortunately takes quite some time.

(As an aside, if all MP3 files vere of the CBR (Constant Bit-Rate) kind, it would be straightforward to seek inside a file, because a given amount of seconds would always correspond to a given amount of bytes in the file. Alas, CBR is not the norm, and there is also no flag in the file that would guarantee it is CBR, so this method cannot really be used generally.)

Still, I have some good news. The issue you have described has, over the years, been taken up just enough times that we are now going to change the MP3 decoder in such a way that it will remember a certain number of rewind points. When implemented, it will make the slow kind of rewind operations perhaps up to 10-30 times faster. Stay tuned on this discussion thread; we might have something for you to test before the end of the week!

Oh, one additional question:
Is it necessary that the files are MP3? If you would have the same audio in the Ogg Vorbis format, you could get approximately 30% smaller files for the same sound quality. Also, Ogg Vorbis files actually contain internal time codes, so seeking in even very large files is practically instant.

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

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

Re: MP3Model/MP3 Codec file seeking behaviour

Post by Henrik » Mon 2019-04-08 16:08

Hello again, Alex!

Today is our Super Duper Express Service Day! Pasi was able to make the necessary changes to the MP3 decoder in record time, so please find attached to this message an experimental version of the MP3 decoder with fast rewind functionality!

We would very much appreciate your comments on the new decoder when you have been able to test it.

Kind regards,
- Henrik
Attachments
decmp3.zip
Zipped version of new decmp3.dl3 for VSOS 3.50 and higher. Copy the .DL3 file to your S:SYS/ folder to try the new MP3 decoder with fast rewind.
(10.56 KiB) Downloaded 15 times
Good signatures never die. They just fade away.

alex_t
User
Posts: 5
Joined: Sun 2019-04-07 12:50

Re: MP3Model/MP3 Codec file seeking behaviour

Post by alex_t » Mon 2019-04-08 20:20

Hi guys!

Thank you so much for your quick response - I read Panu's response this morning and actually did try transcoding our problematic MP3s to Vorbis, as I noticed that this codec was supported.

Sure enough, using this decoder results in instant rewinds, which was going to be my proposed solution. However, I'll give the modified MP3 decoder a try and let you know how it pans out, as using this would obviously be preferable to re-exporting a bunch of customer content to a new file format!

Thanks again, and I'll report back when I've given the new code a test.

Cheers,

Alex

alex_t
User
Posts: 5
Joined: Sun 2019-04-07 12:50

Re: MP3Model/MP3 Codec file seeking behaviour

Post by alex_t » Mon 2019-04-08 21:40

Hey again,

I've updated my version of SYS/decmp3.dl3 with that supplied in the previous attachment, but it seems to prevent the player from decoding any file now. I've confirmed that this is case both on a development board and with one of our devices.

If it's helpful, we're running VSOS 3.33 - is there anything else I need to do to ensure the library will function?

Thanks again for your help!

Alex.

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

Re: MP3Model/MP3 Codec file seeking behaviour

Post by Henrik » Tue 2019-04-09 8:07

alex_t wrote:
Mon 2019-04-08 21:40
I've updated my version of SYS/decmp3.dl3 with that supplied in the previous attachment, but it seems to prevent the player from decoding any file now. I've confirmed that this is case both on a development board and with one of our devices.
Oh, that is very curious. Do you get any error messages?
If it's helpful, we're running VSOS 3.33 - is there anything else I need to do to ensure the library will function?
It actually may very well be the reason. We introduced a new concept - ROM-independent, universal binaries - for VSOS 3.50, and all new projects have been compiled using these universal binaries. This is to ensure binary compatibility with future revisions of VS1005. I may be able to compile the driver in such a way that it doesn't use these new universal binaries; let me get back to you.

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

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

Re: MP3Model/MP3 Codec file seeking behaviour

Post by Henrik » Tue 2019-04-09 10:08

Hello again, Alex!
alex_t wrote:
Mon 2019-04-08 21:40
If it's helpful, we're running VSOS 3.33 - is there anything else I need to do to ensure the library will function?
Attached to this message is a version of decmp3.dl3 that has been compiled with legacy options turned on and should thus work with VSOS prior to 3.50. I'd appreciate if you could try it and tell whether it works for you or not.

Kind regards,
- Henrik

[EDIT 2019-04-09: Removed .DL3 file attachement because it wasn't working]
Good signatures never die. They just fade away.

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

Re: MP3Model/MP3 Codec file seeking behaviour

Post by Henrik » Tue 2019-04-09 10:19

Hello Alex!

I write this in a separate message so as not to mix too many subjects together.
alex_t wrote:
Mon 2019-04-08 20:20
Sure enough, using this decoder results in instant rewinds, which was going to be my proposed solution. However, I'll give the modified MP3 decoder a try and let you know how it pans out, as using this would obviously be preferable to re-exporting a bunch of customer content to a new file format!
If your customers have originally produced the files for you in MP3 format, i.e. you don't have the pristine, uncompressed sources of which the MP3 files were made from in the first place, then I very much agree that it is generally better not to transcode from one lossy audio format (MP3) to another (Ogg Vorbis). Transcoding only leads to further quality loss, even though it might not be noticeable in some cases. Anyhow, let's see if we can get the new and improved MP3 decoder to work for you.

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

alex_t
User
Posts: 5
Joined: Sun 2019-04-07 12:50

Re: MP3Model/MP3 Codec file seeking behaviour

Post by alex_t » Tue 2019-04-09 11:17

Good morning!

I've tried the latest version of the library supplied on our player/dev board and still no luck getting files to decode, sadly.

I've had a look through our device debug logs and have noticed the following error, which I think may be related to what is happening?

Code: Select all

E'Too old APP'
E'lib'
Is there something extra I need to do on my side? Rebuild the project with the same preprocessor directives maybe?

Thank you!

Alex.

Post Reply