Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Patches
  • Category Music playback
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by Uchida - 2010-04-24
Last edited by bluebrother - 2011-06-05

FS#11216 - displayed embedded albumart

It is the patch to display the albumart which is embedded the audio file when this audio file is playing.

support codec: mp3
suppoert formats: JPEG
(necessary: embed albumart size < 96 kB, and bitmapized size < 64kB)

I confirmed iPod photo and video (WPS is cabbie2) only.
please confirm other targets.

Closed by  bluebrother
2011-06-05 10:42
Reason for closing:  Out of Date
Additional comments about closing:  

embedded album art in mp3 files is supported since Rockbox 3.8

Hi,

Hopefully someone will post a more detailed comment, but this patch has been discussed a little in IRC over the past few days, and the concensus is that you shouldn’t be using the codec buffer for this.

Are you able to explain how your patch works? i.e. what memory it is using, and for what purpose?

Thanks,

Dave.

I am sorry for very late the answer. (I busy the work, and there was no time that was able to be work the Rockbox. )

I think that there are the following problems when the bitmap data is registered in the file buffer (general file buffer not codec buffer).

1) Registering the bitmap data in the buffer doesn’t succeed without fail.
Because the bitmap data size is 10kB - 32kB or more, it cannot be registered according to the state of the buffer.

2) There is a possibility that the problem that cannot be played when the bitmap data is registered in the buffer.

  When playing, various data (music file, metada data, codec file, etc) are registered in the buffer. 
 When the big size data is registered, there is a possibility that the phenomenon that data (music, metadata, codec ) cannot be registered in the buffer. (buffer is full)

 therefore, it fails in the performance of music.

These above reasons, I gave up registering the bitmap data in the buffer to display the albumart as surely as possible.
Only the codec file is stored on the codec buffer for most codec files and unused area remains enough.

My patch works well in my iPod. Though I don’t test enough, there are problems.
and other players, it might have to adjust the size of the bitmap data.

the patch file updates

changelog

  1. sync 25898
  2. Correction of stopping of performance sometimes when the repeat is enabled.

patch file updates

changes:

  1. sync 26136
  2. When WPS is changed while playing, the embed albumart is displayed to new WPS.

This time, I create both patch used the codec buffer and the patch that did not use the codec buffer.
I don’t use the codec buffer if problems don’t occur by the patch that doesn’t use the codec buffer.

the patch updates.

changes:

  1. direct decode jpeg to bitmap. (advice for Unhelpful. very thanks)
  2. new jpeg decorder functions add. (read_embed_jpeg_file()/read_embed_jpeg_fd())
  3. does not use the codec buffer.

yesterday’s patch updates.

changes:
- reduce bin size.
- rename read_embed_jpeg_* to clip_jpeg_*.

Are you still working on this?

I wonder why it needs a buffer on the audio buffer, can’t it be loaded directly from the file in the usual way?

I took the above patch and re-did the whole buffering part of it. It now needs no spare buffer and re-uses the existing mechanism by passing the audio file directly to the image loader (acting as if it were an image file, with proper lseek()).

The parser gives incorrect offset for my test file which I needed to fix with an additional 27 bytes. I guess this is some alignment.

This should fix the metadata parser issue I mentioned.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing