This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#11216 - displayed embedded albumart
Attached to Project:
Rockbox
Opened by Yoshihisa Uchida (Uchida) - Saturday, 24 April 2010, 10:48 GMT+2
Last edited by Dominik Riebeling (bluebrother) - Sunday, 05 June 2011, 12:42 GMT+2
Opened by Yoshihisa Uchida (Uchida) - Saturday, 24 April 2010, 10:48 GMT+2
Last edited by Dominik Riebeling (bluebrother) - Sunday, 05 June 2011, 12:42 GMT+2
|
DetailsIt 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. 
rb_albumart.patch
(20.5 KiB)
b/apps/codec_thread.c | 4 b/apps/metadata.h | 20 ++++ b/apps/metadata/mp3.c | 48 ++++++++++ b/apps/playback.c | 162 +++++++++++++++++++++++++++++----- b/apps/playback.h | 10 ++ b/apps/recorder/jpeg_load.c | 206 ++++++++++++++++++++++++++------------------ b/apps/recorder/jpeg_load.h | 11 ++ 7 files changed, 350 insertions(+), 111 deletions(-) |
This task depends upon
Closed by Dominik Riebeling (bluebrother)
Sunday, 05 June 2011, 12:42 GMT+2
Reason for closing: Out of Date
Additional comments about closing: embedded album art in mp3 files is supported since Rockbox 3.8
Sunday, 05 June 2011, 12:42 GMT+2
Reason for closing: Out of Date
Additional comments about closing: embedded album art in mp3 files is supported since Rockbox 3.8
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 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 Ｉ don't test enough, there are problems.
and other players, it might have to adjust the size of the bitmap data.
changelog
- sync 25898
- Correction of stopping of performance sometimes when the repeat is enabled.
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.
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.
changes:
- reduce bin size.
- rename read_embed_jpeg_* to clip_jpeg_*.
I wonder why it needs a buffer on the audio buffer, can't it be loaded directly from the file in the usual way?
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.