Hi,

FLAC tags don't seem to support including album art in the metadata. Although I'm not exactly aware of how software currently use album art in mp3 files, I think it would make a nice addition. It would get using one's FLAC archivce in daily use a bit closer to using the original albums, don't you think?

Is there some direct technical reason why not include it?

Rgds,

.brum

the problem with cover art in tags is that the people who do this obviouly know nothing about scanning ... there is not hundred ways to scan a cover ...

for Optimized Quality Vs. Size It's
Real Size                  = CD Front (24X12cm)      CD Back (15X11.8cm)
300DPI Scale 100%  = CD Front (~2824X1412px) CD Back (~1768X1388px)

either as Jpeg 80% or PNG, (or 150DPI px/2 if you don't really care for printing)

but there is hundred of sub-optimal ways to scan them 72-75-96-100DPI with scale 100 or 200% or 200-400DPI scale 100% instead of 150-300DPI, I even saw 600DPI scans ...

Edit: To be fully exact personnaly I use first front only 12x12cm=1417x1417px aka 300DPI 100% Scale PNG ... exact size at pixel precision ... (~3mo/cover) that's what I consider "lossless" cover for my lossless audio ... even if lossless scan is a myth ...

so actually there is no real standard for cover outside tags ...

now inside tags there is often a limited size (in ko) you can set for the cover,

so people often take their already sub-optimal jpeg & resize (transcode) it down to let's say 200X200px to make it fits in the tags ... the result of this is that when you have a cover in an mp3 tag, you got a thumbnail of the front cover but nothing more ...

you can't print it & you don't have the back cover, the displaying support of it is bad ..
so in the end is it really usefull ? just open google & make a search for the album name & there is 90% chance you will find a thumbnail easyly ...

it's only usefull if you don't have internet, for cover preview, you don't intend to print ...
& even in this case a full 300DPI scan of the artwork will always be better ...

... artwork in tags isn't really interesting ...

as long as audio players will not be image browsers I even think it's completly useless ...

& I don't think I will browse & print my jpeg with winamp in the near future, if you see what I mean 

@Oggzelot
chill out...its the year 2005 one might like to have a thumbnail inside the tag and use a compatible software/hardware player to display it. We are NOT talking about professional CD cover reproduction.

@.brum
FLAC files use Vorbis comments for their tagging needs, and Vorbis comments are 100% text only by design.

jtclipper:
I agree but if for printing you need higher quality, in the end you get doublon which is the contrary of the purpose of including jpeg in tags I think ...

I don't say including artwork in tag is always a bad idea ... but I say that it doesn't worth it if you must destroy the quality to fit a target size ...

It must be done cleaner than the hack I saw in mp3 ... if you could import/export state of the art quality scans in it maybe I would like it ...

.brum take mp3 as a comparison ... & I don't think it worth it the way I saw it was done with mp3 ... with mp3 it's not real cover, it's cover preview ...

now if you could add full covers the right way, why not ... afterall

the problem with cover art in tags is that the people who do this obviouly know nothing about scanning ... there is not hundred ways to scan a cover ...
[a href="index.php?act=findpost&pid=285442"][{POST_SNAPBACK}][/a]

OggZealot,

Thanks for the reply. I hadn't actually thought about printing or scanning, but rather use some tool (like Arbum Art Tool) to download and integrate thumbnails. Just for browsing and livening up the song listings.

rgds,

.brum

@.brum
FLAC files use Vorbis comments for their tagging needs, and Vorbis comments are 100% text only by design.
[a href="index.php?act=findpost&pid=285471"][{POST_SNAPBACK}][/a]

jtclipper,

Thanks, this explains it. I guess that we won't see a change in this anytime soon, then .

Rgds,

.brum

Wouldn't it be possible to UU encode images so that they would be text and therefore storable in the tags?  Sure, nothing would support it unless you wrote the interface yourself, but it is possible, none the less...

How about this: storing Ogg MNG album art with Ogg FLAC.

The format allows this.

Wouldn't it be possible to UU encode images so that they would be text and therefore storable in the tags?  Sure, nothing would support it unless you wrote the interface yourself, but it is possible, none the less...
[a href="index.php?act=findpost&pid=285476"][{POST_SNAPBACK}][/a]

a program already supports this storing images and the mime type into 2 separate fields, I know that cause it crashed my program trying to load a 130Kb value in a standard Delphi string...

Hacking the format sucks, if the guys who developed the format did not include binary fields in the first place then just leave it like that..even APE tags that have support for binary fields do not enjoy full support from software because of their lack of standardized fields, Vorbis comments lack both.

The idea of abandoning the metadata and trying to muxe an image is rather exotic cause nothing in this world would support something like that.

So it is inherit by design either use another audio format or just accept it.

to sum up:

1. there is no standardized way to store it in FLAC

2. you could do it by converting binary to utf-8 (uuencode, etc) and stuff it in vorbis comments.  this is a hack as vorbis comments are supposed to be for human-readable stuff.

3. you could create a new APPLICATION metadata block according to your own design and put it in there with some tool.  that is what the thing that jtclipper mentions does.

4. I've been talking to the guy who wrote that, we have agreed on having a general "mime-type" metadata block to be added to FLAC.  it's on the TODO list but I probably won't get around to it for a while.

my personal opinion is that this belongs in a separate metadata database (which is how I do it with my own collection) or muxed in a proper container.

Josh

This would create something that is very incompatible with the way metadata is stored in all other audio formats.

I believe that the Vorbis comment has to evolve. It must standardize the field names and add support for binary data. Apps will react and in a very short time everybody will be happy.

This would create something that is very incompatible with the way metadata is stored in all other audio formats.

I believe that the Vorbis comment has to evolve. It must standardize the field names and add support for binary data. Apps will react and in a very short time everybody will be happy.[a href="index.php?act=findpost&pid=285530"][{POST_SNAPBACK}][/a]

but FLAC already has a metadata mechanism for storing binary metadata.  and the most common field names are already a de facto standard.  not much beyond that can be standardized because no one agrees what it should be.  just look in the vorbis mail archives for the huge inconclusive threads on metadata.

that's why I say a big metadata standard should be separate from an audio codec and muxed in if it has to be part of file storage.

Josh

Metadata should be an one way stop for any kind of file, multiple metadata blocks for the same purpose (tags) only increase the complexity and do not provide any practical benefit.
I strongly believe that all the world needs is a simple tagging standard with an array of standard fields ( text & binary ) and guidelines for their usage. User fields can be used just like that as well.
One of the most hated standards here the ID3v2,  provides those already, it really sucks in other areas like character encoding mayhem.. but it still sets guidelines and that is why it can be of use in a large array of software and hardware implementations.

Complexity would mean limited software support, why would anyone scan the Vorbis comment for tag data and yet be forced to scan other metablocks just in case a picture exists ( if not more ) and it would have to re create and re write all that stuff. Some things I do not understand like wma ( asf.. ) metadata , they have the 'simple' thingy' with a few fields and then the real thingy with all fields and a developer has to read and write that crap twice.

One metadata object with all the relevant info and in on place in the file or the container format with standard fields is by far the most efficient way IMO.

you sound passionate about it and have some good ideas, maybe you should spearhead a new open metadata standard.  except for id3v2 (and maybe matroska, not sure) no one has really followed through with it yet.

Josh

I did have some ideas some time ago and also published them in this forum, but the result was some short sighted guys pounding on me.
Most people here would close their eyes to something new and complete, dedicated to audio tagging, and they bite on the first chance they get, sure APEv2 tags are a very good starting point but they are not perfect.

Anyway maybe its the wrong place to start a conversation like that in this forum and it IS a pity.

The best chance for a new tagging format to evolve and enjoy full software and why not hardware support is for a native audio format to officially adopt it.

I would like to see a Vorbis comment v.2 or and APEv.3 or why the hell not an ID3v.3 combining good features only. The tag data chunk could reside inside a container format or just act as a 'stick it on me' like ID3v2 or APEv2.

I believe that the Vorbis comment has to evolve. It must standardize the field names and add support for binary data.
[a href="index.php?act=findpost&pid=285530"][{POST_SNAPBACK}][/a]

You can't standardize tags, because you can't standardize words, because you can't standardize thoughts.
[a href="index.php?act=findpost&pid=232067"][{POST_SNAPBACK}][/a]

Efforts to standardize language are doomed to fail.

Anyway, I doubt if anything besides Ogg muxing would ever take off.

Efforts to standardize language are doomed to fail.

We are talking about tag frames here.
ID3v2 has them and I am not sure it failed, every major appliance supports it out of the self ( DVD/ car audio/pocket players and so on )

Forget language think coded frames, if you cannot, then think of mp4 atom names.

Simple isn't it ?

I was thinking of changing over to FLAC, but I'm not sure yet.  So, what's the decision for album arwork integration?  I'm using (NI) Native Instrument's Traktor and they don't support album artwork yet.  I know that AAC files have the ability to have artwork added, but I'm not sure if I want to encode all my wavs to that.  I have over 1000 JPGs of my vinyl covers & I HOPE that one day I can have them incorporated with my music.  I'm trying to get NI to utilize some sort of search that utilizes pictures.  Hell, I used to flip through my record crates LOOKING for colors & patterns of specific records that I remembered.  Our brains work visually for the most part.  I can't remember the thousands of Artists & Titles of each of the Artists all of the time.  A visual search would rock for me.  The closest thing I've found is Picasa2 from google ~ the visual timeline thingie.

The bottom line is that I would rather NOT have a seperate database that I keep my JPGs in.  I want them integrated so that when Traktor is no longer the program to DJ with...I can port over my collection easily.  I do NOT want to get tied to one program forever.

Thoughts?

PS:  If you do add this ability...let me add as many JPGs as I want.  I have some vinyl covers that fold out & have upwards of 4 JPGs per. 

This is just an idea but if you really want to have art album, all songs and tags in one single file try to use Matroska... I think that´s one of the intention of Matroska...

Thanks for the info, but I want to stay with a format that works with my DJing software.  FLAC is one of the supported formats.

Use FLAC in matroska, and use any DShow player for playback. Haali's splitter will display album art in the MKA attachement, if its JPEG.

Christian
matroska project admin
http://www.matroska.org

EDIT : screenshot