Add support for album art export

[danielkinahan]

I'm interested in taking a crack at this since I like to have the little pictures on my screen lol. We would need to extract the image tag from the song metadata and insert it into the AlbumArt table as a 256x256 png blob.

Here's a screenshot of the actual Engine DJ Desktop export (it works using wine btw)

One thing I need your feedback on is the extraction since we'll have to use a lib. TagLib is used by Mixxx which is the direction I'd like to go but including it in this project would be duplicating code. Could we have different cmake instructions for building this lib standalone vs in Mixxx?

I have parts of the solution in a branch on my fork https://github.com/danielkinahan/libdjinterop/tree/album-art-attempt
If you have time to take a look that would be awesome.

[mr-smidge]

I took a quick look through the branch on your fork, and at a high-level this looks like a good approach to me (though I haven't done a detailed review).

One question: why do you feel that libdjinterop has to implement extraction of artwork from song metadata? Up to now, I have designed libdjinterop so that it doesn't have to understand file formats or attempt to read music files: the caller of the library would be expected to already have the album art they want to associate with a track in the library.

[danielkinahan]

That's a good question and you would probably know best. I use this library with Mixxx and I don't have a good grasp of how that program stores cover art although I do see a few columns in the mixxx db library table that hint at it.

What do you think would be the best approach? I think it would definitely be simpler to not perform any extraction on the libdjinterop side, especially for testing.

[mr-smidge]

That's a good question and you would probably know best. I use this library with Mixxx and I don't have a good grasp of how that program stores cover art although I do see a few columns in the mixxx db library table that hint at it.

What do you think would be the best approach? I think it would definitely be simpler to not perform any extraction on the libdjinterop side, especially for testing.

Hi @danielkinahan , sorry for not replying to this sooner.

My recommendation would be:

• Implement the "low-level API" by offering the album_art_table class for V2 and V3 (I think it's the same so you can get two for the price of one).
• Don't implement the export_artwork header/compilation unit - I think decoding of file formats to extract album-art metadata belongs outside of libdjinterop.
• The "high-level API" in include/album_art.hpp is meant to represent a way to get access to album art without necessarily being tied to any specific implementation. This is a difficult tightrope to walk when the library only implements Engine today, but imagine if we were to add Rekordbox support tomorrow, ideally the high-level API wouldn't have to change.

If it's not obvious how to do the high-level API, there is still lots of value in delivering a PR with only the low-level API and tests!