> That would work, but some buffers would get byte-swapped twice on
> big-endian architectures (or little-endian, depending on the exact
> inplementation). With two functions, you byte-swap only when needed. Not
> sure if anyone would notice on such small buffers, but let's keep this
> in mind.
The second byteswap would basically be free since the data would be in a
register or in a cpu register anyway, I'd rather take the potential
performance hit (we are reading from disk anyway, so anything we do from
memory will be nearly unnoticeable) rather than duplicating this code
> > Wrt /* TODO: find a more general way to determine endianness */,
> > http://ipodlinux.org/ITunesDB#Artwork_Database says [...]
> > This probably applies to the Nano too, except that the sizes are
> > different. One would have to look closely at the unknown fields in the
> > database to try to guess if there is a flag somewhere indicating if the
> > data is byteswapped or not.
> Well, just as with the stride value, unless this is explicitly spelled
> out somewhere in the db, I think the only reliable indication of the
> correct endianness is the size of the BGR 565 data. But I need to learn
> more about this stuff, keep in mind that I started yesterday. :)
Does this mean you haven't started looking at hexdumps from your Photo
Database? Looks like you'll have a fun week-end :p
> > Isn't it possible to create your own Itdb_PhotoDB instead of creating a
> > fake Itdb_iTunesDB with dummy songs? This would be cleaner, and much
> > less memory hungry, though it requires more hacking on existing libgpod
> > code I guess.
> I didn't wade through all the code, so I don't have a big picture of all
> the pieces and I'm not sure what's the best course of action. My
> implementation was relatively easy and didn't touch too much code. Doing
> it differently would mean duplicating a few functions that now operate
> on a song and/or an Itdb_iTunesDB, or rewriting them to be more general.
Yep, that's a bit more work to do it cleanly, and you'll need to
understand the existing code a bit more I guess. Don't hesitate to ask
questions about it though
> > For image names and things like that, you'd have to add support for
> > parsing more fields from the photo database, [...]
> Ah, I thought so... but I was hoping the code was already there, just
> hidden where I didn't find it yet. ;)
This should be pretty easy to add, it's all done in db-artwork-parser.c,
which shouldn't be too difficult to read. I can write a more detailed
explanation later if needed.