Rockbox

Tasklist

FS#11216 - displayed embedded albumart

Attached to Project: Rockbox
Opened by Yoshihisa Uchida (Uchida) - Saturday, 24 April 2010, 08:48 GMT
Last edited by Dominik Riebeling (bluebrother) - Sunday, 05 June 2011, 10:42 GMT
Task Type Patches
Category Music playback
Status Closed
Assigned To No-one
Operating System All players
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

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.
This task depends upon

Closed by  Dominik Riebeling (bluebrother)
Sunday, 05 June 2011, 10:42 GMT
Reason for closing:  Out of Date
Additional comments about closing:  embedded album art in mp3 files is supported since Rockbox 3.8
Comment by Dave Chapman (linuxstb) - Thursday, 29 April 2010, 10:44 GMT
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.
Comment by Yoshihisa Uchida (Uchida) - Friday, 07 May 2010, 11:41 GMT
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.


Comment by Yoshihisa Uchida (Uchida) - Saturday, 08 May 2010, 12:52 GMT
the patch file updates

changelog
- sync 25898
- Correction of stopping of performance sometimes when the repeat is enabled.
Comment by Yoshihisa Uchida (Uchida) - Tuesday, 18 May 2010, 11:09 GMT
patch file updates

changes:
- sync 26136
- 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.

Comment by Yoshihisa Uchida (Uchida) - Thursday, 03 June 2010, 11:42 GMT
the patch updates.

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



Comment by Yoshihisa Uchida (Uchida) - Friday, 04 June 2010, 10:34 GMT
yesterday's patch updates.

changes:
- reduce bin size.
- rename read_embed_jpeg_* to clip_jpeg_*.
Comment by Thomas Martitz (kugel.) - Sunday, 30 January 2011, 14:25 GMT
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?
Comment by Thomas Martitz (kugel.) - Sunday, 30 January 2011, 18:13 GMT
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.
Comment by Thomas Martitz (kugel.) - Monday, 31 January 2011, 02:18 GMT
This should fix the metadata parser issue I mentioned.

Loading...