Rockbox General > Rockbox General Discussion

New user constructive feedback

<< < (3/3)

Llorean:
I think "embedded album art" is more or less just waiting on some final decision about jpeg-in-the-core, which probably needs someone to figure out how much (or little) it'll hurt binsize (especially for low memory targets).

As to resizing, it's been discussed to no end with it most often (but not always) settling as "wanted, but it should resize on load/buffering so that it's small in-memory and use as little memory during resizing as possible"  I believe. I think some work is already being done on this, but you never know how that'll turn out.

saratoga:
So a patch that decoded JPEG files on the fly, resized them, and then stored them as BMPs in the audio buffer would be acceptable?  Assuming of course that it was done at reasonable RAM cost of course.

How about an embedded?  I suppose that should work the same?  Is it expected that the art be removed from teh tag during buffering as well?

Llorean:
Decoding JPEG files and resizing them should be separate (as we don't want to remove support for the existing bitmaps, and they should be resizable in the end too). But yeah, I'm almost certain it would be acceptable.

As for embedded I would expect that the decoding to LCD format and resizing should happen during buffering so that what's on the buffer is raw and ready for use in the WPS, and I would expect you wouldn't also keep the original compressed data around. I'm not sure what other people expect, but the impression I got is similar: Any decoding/resizing should happen during the loading of the image.

shotofadds:
I'd recommend MediaMonkey as an excellent music management tool for Windows - it can sync to MSC devices just as well as MTP ones, and can copy over your folder.jpgs (or extract embedded art if necessary) during the sync process.

It's then a relatively simple step to run one of the existing album art conversion tools over the contents of player. A MediaMonkey plugin might already exist to do this, or if not, one could be written relatively easily.

Even so, I do think our album art support could use some "usability" improvements. For me, resizable .jpg support would be the "ideal" usability winner, and I think it's well worth a chunk of extra RAM/binsize (at least on high-memory targets).

Of course, the real barrier is finding an interested developer with the time to spend implementing these things....

Navigation

[0] Message Index

[*] Previous page