[gpodder-devel] Cover Art for Filesystem-based MP3 Players
- From: thp at perli.net (Thomas Perl)
- Date: Sat, 11 Oct 2008 13:33:30 +0200
Hi there!
On Sat, 11 Oct 2008 03:59:03 -0700
<daggpod at emailias.com> wrote:
> The Sansa Fuze supports cover art in the form of a file called
> "folder.jpg" in the directory where the podcasts reside. There is a
> restriction on the size of this file. The Fuze's screen is 220x176,
> making anything over 176x176 a waste of space. The player will scale
> the image to fit the screen, but if it's over a certain size
> (something like 300x300), the player shows a black box instead.
So, ideally, for your player, you would take the cover file, resize it
to be exactly 176x176 (crop anything that goes beyond that) and copy it
to the player as folder.jpg, right?
I suggest you implement the cropping and resizing as a specialized
function that you can later put into src/gpodder/util.py and that
utilizes the PIL (python-imaging in Debian/Ubuntu).
See: http://www.pythonware.com/library/pil/handbook/introduction.htm
You can easily create a standalone app that resizes an image to
176x176, test it that way and then transform it into a function that
takes two parameters: one is the filename of the source image and one
of the destination image.
After that works, I suggest you parameterize the side length (176 in
your case) and add this as third parameter to your function.
When you have got the function correct, you just need to add it to
src/gpodder/util.py and use it in src/gpodder/sync.py, where you can
use the iPod code as an example.
For the configuration options, I suggest having three configuration
options:
mp3_player_copy_coverart -- boolean (should coverart be copied?)
mp3_player_cover_filename -- string (how should it be named?
"folder.jpg" in your case)
mp3_player_cover_size -- int (maximum image size? 176 in your case)
Add these to src/gpodder/config.py and then you can access is as
"gl.config.[name of the configuration variable]" in your code.
> I'd imaging each player has its own quirks as to the image file name,
> its appropriate format or whether it supports the image as an
> embedded tag (the Fuze doesn't). So I was considering how best to
> implement this so other players could be easily supported without
> adding a few dozen player-specific classes to sync.py.
I suggest you implement it as described above. You don't really care
for players with embedded tags currently, so it's perfectly fine to
make your patch so that it works for your MP3 player. If you make it as
modular as we have seen above, it should be no problem to extend that
functionality later on, should anybody else care :)
Feel free to come back to me for any questions you might have.
Good luck!
Thomas
Other related posts:
