Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide
translations



Rockbox mail archive

Subject: Re: Embedded albumart

Re: Embedded albumart

From: David Hall <dmhall_at_gmail.com>
Date: Sun, 13 Feb 2011 19:28:29 -0500

On 02/13/2011 07:05 PM, Paul Louden wrote:
> I took your statement "it cannot be fixed on the player" for granted,
> and didn't exam it, I'll admit that. So given that it's easier to fix
> the proposal where individual filed overrides embedded, but embedded
> overrides folder (and everything else) on the player, than having files
> always override embedded, are there other concerns? That being said, I
> could argue that you should've examined the original proposal you were
> against more thoroughly and caught that it could indeed already meet
> your needs. ;) We both missed it.

No, my only concern (upon reexamining) is that embedded does not trump all.

>
> I will say, it may not *always* be easier to fix, but I think the
> assumption that the majority of files will either have intentional
> embedded album art, or not have it, and that it will be a minority that
> has unintentional embedded album art is the one we should make.

An example of where it is not always easier to fix the track.jpg >
embedded > folder.jpg scheme:

For podcasts, I currently have a directory per program with a jumble of
episodes (downloaded whenever, wherever, possible) and a folder.jpg in
said directory. I'll bet most of those podcasts have embedded art.

Embedded art not being at the bottom of the food chain means I'll be
"forced" to create lots of track.jpg folders if I want to maintain my
current look. But that doesn't really matter. Fact is I _can_ if I
feel the itch and that is what makes me satisfied. And I can fix this
on a work PC quickly, without having to install (which I can't do) a
tagging program.

--soap
Received on 2011-02-14

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy