I just wanted to having it separately written down as a topic. It seems that there are some threads (that I already read) about people having problems with "progressive" or "baseline" cover art images because of some older devices that do not support "progressive" ones. I am aware the the "solution" should come from the programmers of these old devices (but let's be reallistic, we all almost know that they won't do anything but suggest you to buy new/modern devices). I know that "progressive" is better since it also reduces filesize but people being stuck of their old devices do not have much choices.
Like some of you might already know MP3Tag is now capable of cover art processings (via "Adjust Cover") which is really cool. At this point I also wanted to thank Dough_Mackie and Ohrenkino.
It would be really nice if MP3Tag would in future also have an indicator/field that shows if an cover art is in "progressive" or "baseline" so users will directly know which cover art they have to adjust to make it work on their "old baseline only"-device(s). With showing this indicator/field there won't be the need (at least for me) to use any other additional/external program anymore.
The current "cover type"-column shows for example if it's a "front cover", "back cover", etc. Maybe the feature I am requesting could be labeled "Cover Compression Type" with the options "Progressive" or "Baseline" (or boolean "Progressive/Baseline: True" and "Progressive/Baseline: False" which looks worse).
Of course I am aware that MP3Tag is not a "graphic" programm so I would fully understand if this request will/can not be fullfied at all.
Anyway I am thankfull for all that is available right now. I love the community and the developers. Keep up the good work.
Have a nice and relaxed sunday.
PS: Maybe not limited to an extra column, but this info could also (or only) be added to the section where the details about the cover are shown (for now it shows on the righthand side of the cover art e.g. "image/jpeg | 600x600 | 262 KB | Front Cover", what it should additionally show via my request is "image/jpeg | Progressive | 600x600 | 262 KB | Front Cover" or in paranthesis: "image/jpeg (Progressive) | 600x600 | 262 KB | Front Cover").
Just a side note:
This information only helps if you already know what the difference between "progressive" and "baseline" JPG picture is and which of this two formats you need for your device.
If you know - for example - that your car player needs "progressive" covers and all your other devices play both formats, you can just convert all of your covers from whatever format they actually are to "progressive".
If you need different formats for different devices, you would need to copy your files for this device and adjust the covers.
Yeah, for sure you need some background knowledge . But this is also the case for (m)any other feature(s) in MP3Tag (or maybe in knowing tags, format etc. in general so program-independent). But once you know, this indicator/field will be very helpful and saving you time. Whatever format your device needs/supports is another question/topic but not directly related to this feature request, so please let's not digress .
since noone wrote in here and it's quite for almost 10 days, I did some further research and thanks to Ciobi and all of his work I found something. Since MP3Diags is open source (see SourceForge or Github) I looked how he solved this.
//QPixmap img; // !!! QPixmap can only be used in GUI threads, so QImage must be used instead: http://lists.trolltech.com/qt-interest/2005-02/thread00008-0.html or http://lists.trolltech.com/qt-interest/2006-11/thread00045-0.html
QImage img;
const unsigned char* pBinData (reinterpret_cast<const unsigned char*>(pImgData));
int nSize (pFrame->m_nMemDataSize - (pImgData - pFrameData));
if (img.loadFromData(pBinData, nSize))
{
pFrame->m_nImgSize = nSize;
pFrame->m_nImgOffset = pImgData - pFrameData;
pFrame->m_eApicStatus = pFrame->m_nPictureType == Id3V2Frame::PT_COVER ? Id3V2Frame::COVER : Id3V2Frame::NON_COVER;
pFrame->m_nWidth = short(img.width());
pFrame->m_nHeight = short(img.height());
if (0 == strcmp("image/jpeg", szMimeType) || 0 == strcmp("image/jpg", szMimeType))
{
pFrame->m_eCompr = ImageInfo::JPG;
const unsigned char* p (pBinData);
for (int i = 0; i < nSize - 1; i++)
{
unsigned char c1 (*(p + i));
if (c1 != 0xff)
{
continue;
}
unsigned char c2 (*(p + i + 1));
if (c2 == 0xc0)
{
// baseline (i.e. non-progressive)
break;
}
if (c2 == 0xc2)
{
// progressive
MP3_NOTE (pFrame->m_pos, id3v2ProgressiveJpeg);
break;
}
}
}
else if (0 == strcmp("image/png", szMimeType))
{
pFrame->m_eCompr = ImageInfo::PNG;
}
else
{
pFrame->m_eCompr = ImageInfo::INVALID;
} //ttt2 perhaps support GIF or other formats; (well, GIFs can be loaded, but are recompressed when saving)
return;
}
So it seems to me that it's checking for the binary; "0xc0" for non-progressive and "0xc2" for progressive.
Hope this will sky rocket the help to add it into MP3Tag soon.
I would prefer that the Progressive property have its own filter syntax rather than a default column, since much of the time the column entry would be not be needed (i.e. for baseline). A filter expression would be more efficient. It would be available when needed without taking up valuable real estate in column view.
The progressive JPEG format is quite old and I see no benefit whatsoever from using it in audio tags. Moreover, baseline JPEG is recognized by players old and new. So I feel that progressive images in audio files are nothing but trouble.
A popup warning would be nice when attempting to save progressive images into music files. Something like "Do you really want to save this image...".
Progressive jpg covers are in a valid jpg format.
Progressive jpg files cause problems in some players - so it is mainly a player problem. Usually such a player does not show the image as expected.
Players with a decent implementation for pictures would never let the user notice the variation in grafic format.
What would be the way to overcome this problem?
I think the only way would be to re-encode the picture again - e.g. from jpg to jpg or png - from a lossy format to another lossy format.
This is already possible in MP3tag with the action to adjust the cover.
I admit that a property variable to filter for progressive jpgs would be more comfortable than check whether the player properly shows the picture.
The remedy, though, is there already.
I completely agree that if an option becomes available to differentiate these progressive versus baseline images, that this would ideally be a filter option. Of course like all other fields though, the convenience of choice is likely the best of both worlds.
you all did some correct points. Most of them are already known to me and some of them I already mentioned in my very first post. So it might be that I did not expressed myself well enough (sorry bad english).
To re-cite myself:
Like some of you might already know MP3Tag is now capable of cover art processings (via "Adjust Cover") which is really cool. At this point I also wanted to thank Dough_Mackie and Ohrenkino.
But if you do not know which covers you need to re-encode in the first place you might have to use different programms or players/devices. This is tedious. Of course you could just re-encode all of your files just to be sure/safe since MP3Tag always encode to "Baseline" but depending on your library this might take up to much time to process. A filter might be a solution so that you really "only" re-encode your "non-baseline" covers.
Additionally having it displayed next to the cover information and/or as an optional column would be very comfortable.
I tried to edit an image that could help to express myself better (my edits are written in red to make it more visible and my edits skills are bad, I know).
Regarding "[1]": I do not know what you might consider as "standard" and don't want to argue about that. So to me it does not matter which variant you would finally choose to add to MP3Tag. There could be either "[1.1]" which assumes Progressive is the "standard" and would state "Yes" or "No. If you would take [1.2] "Baseline" as "standard" (which sounds to me closer because "base") than it woul be the same thing as above. If you would not like have it as "Yes/No" then we could go with "[1.3/4]" (either it shows "Progressive" OR "Baseline", sorry I should have labeled both "[1.3]" in the picture like I did correctly in part "[2]").
Regarding "[2]": I do not know what you might consider as "standard" and don't want to argue about that. So to me it does not matter which variant you would finally choose to add to MP3Tag. The column "Cover Compression Type" could show "Progressive" or "Baseline" to be unbiased instead of the variations of "Progressive/Baseline: Yes/No".
It is not necessarily needed to have "[1]" and "[2]" added in my opinion, but having both options would of course be even nicer. The column variant is an optional one (which will not be shown by default, so people do not get confused when they are not up into these kind of things).
I hope that I have now expressed myself more clearly. Let me know what you think.
Please note that this feature would also have to take care of pictures in png format which do not appear with progressive encoding and probably do not have this attribute.
Maybe put "png" as an additional option to each of my mentioned ones (of course it will not be possible to the "Yes/No"-variants but to the others I guess)?
Meanwhile what came to my mind some minutes ago is this:
Maybe it should not even have to be an extra field but could be added to the existing "image/filetype" field which is positioned on the right handside of the cover. It could then either show [4] "image/jpeg (Baseline)", "image/jpeg (Progressive)" or "image/png" (are there more variants?). Since I never had png-covers (but others might have) and I am not at home right now I am not sure how png-covers are marked/displayed in MP3Tag (plus MP3Diags) currently but I will test/look it up (hopefully tonight) or maybe you can tell it to me directly.
But it could be that in this version it is still needed to filter since you do not want to click on each file to see which cover compression type it has.
Here is the updated version of my previous picture:
then no new property variable would be necessary but you could filter for the files with
%_cover_mimetype% HAS jpg
(for all jpgs)
%_cover_mimetype% HAS progressive
(for only the progressive ones)
%_cover_mimetype% HAS baseline
(for only the "normal" ones)
and
%_cover_mimetype% HAS png
for the pngs.
That looks to me like the most attractive solution.
I need some time to look into this (when I'm home tonight).
But to quickly ask until then:
Wouldn't a filter for "NOT %_cover_mimetype% HAS baseline" (maybe the "NOT"-operator has to be placed somewhere else) give the wanted results (because then it should also include pngs besides progressive jpgs if I'm not mistaken)?
AFAIK %_cover_mimetype% returns a string which can be evaluated in the filter like any other string. So I would expect the NOT to work as expected i.e. show all covers that are non-progressive.
Now that I am at home I have tested it. Unfortunately it does not work (neither "NOT %_cover_mimetype% HAS baseline" nor "%_cover_mimetype% HAS baseline"). Before checking with the "NOT"-Operator I tried wihout it but also without success.
I could not find what the possible outputs of "%_cover_mimetype%" could be on the MP3Tag pages but on another website. It seems like mimetype does not contain more information than "jpeg" (or "png" etc.), so no "Baseline" or "Progressive". That might be the reason why it is not possible to filter for these.
Would have been to easy, right :)? We have to find other ways.
Oh, this must have been a misunderstanding: you are right that currently you cannot find progressive or baseline covers.
But if the feature should be implemented then I would favour the addition of text to the existing %cover_mimetype% instead of a separate property which might cause problems with other grafics formats than jpg.
Oh, well, yeah... misunderstanding. Thought it was already possible because of your previous response (last sentence):
So I would guess that it will not be possible via %_cover_mimetype% since it seems to not support it officially IIRC.
Maybe we think to complicated or don't see what before our eyes. Does the code snippet not help someone in here (since it's a code that works on there)?
It does not really matter for me in which way it gets implemented (whether it'll be a filter or some options of my posted picture), it's only important for me that it gets implemented at all (additional options could still be added later).
Note that a JPEG file can contain a variable number of blocks or "markers". They may include another smaller JPEG image as a thumbnail. It is possible for a value of 0xC2FF to occur within them with a different meaning. I suspect that a device that can't read progressive encoding might also have a limited memory or choke on very large metadata.
There are programs like IrfanView that can convert between progressive and linear scan in batch mode, Of course the task of reinserting the images into tags still remains. This is one of the reasons why I prefer external cover artwork. It can also be upgraded more easily for quality.
. But this is also the case for (m)any other feature(s) in MP3Tag (or maybe in knowing tags, format etc. in general so program-independent). But once you know, this indicator/field will be very helpful and saving you time. Whatever format your device needs/supports is another question/topic but not directly related to this feature request, so please let's not digress 
.
