Is metadata really 'in' the file? Is the art in the metadata or elsewhere?

Hi,
Is metadata really ‘in’ the file? I mean i know it is, just getting a bit confused by what picard says and my music player says. I suppose the real question is: is the cover-art actually metadata? and if so, is it in the music file? I think not but then where is it?

Let me explain why so confused:

have 100+ albums ripped to mp3 on an ubuntu NAS. Have used picard on ubuntu NAS to get metadata and cover art. Now looking at the files from a RPi + moode streaming box on the same network. I am browsing the files through the streaming appliance’s web page.

I see a list of albums, a few have thumbnails. I go to one without thumbnails and play it, the cover art comes up on the play page. Sitting back in front of the ubuntu NAS, I cannot find the cover art for that album in the folder. Is the image hidden in a track metadata? None of them look much ‘bigger’ than the others but I do not think moode ‘fetches’ the art.

If I go to (on the streaming appliance page) one of the albums with a thumbnail, it appears for all of the tracks in that folder. If I go to another also with a thumbnail, it only appears for the first track. So is the thumbnail metadata and sometimes included in one track and sometime in the whole group of tracks? On the ubuntu nas (has a desktop) I cannot see a thumbnail file in the directory for either album?

I find 2 albums from the NAS desktop, both with 4 files: (only 2 like this)

  1. cover_art_large.jpg
  2. cover_art_small.jpg
  3. thumbnail.png
  4. index.jpg
    Looking from the appliance web page, they have thumbnails, and highers res art in the play page. In the NAS desktop I rename file 1. in one album with ‘NOT’ prefix. I rename file 2, 3, 4 in the other album folder also with the ‘NAS’ prefix. This should break one album one way and the other album the other way, I do this as an experiment to test where the files are. I restart the samba server and remount the share from the appliance streaming rpi. From the appliance streaming pi I can see thumbnail art in the browser page for both albums, and full art in the play page for both albums. So it must be in some metadata in the mp3 file?

Equally, my wife copied a load of music to a massive usb stick, and put it in her car. Almost every album has the right cover art, but I cannot see it in the folders. Is her car finger printing the mp3s and fetching the art? It should not do, not sold with this and to what is it connecting? It has not got a sim as far as I know and we have not given it any wifi codes with it on the drive. I cannot find these images in the folders, but some I can, but I did not put them there I think picard did.

This all seems to suggest sometimes the image is in the metadata of a file, sometimes it is not. Can you explain? (or do you have a nice link I am missing on my google searches about this?)

1 Like

Image can be in the file tags (metadata).
Image can be in the folder, as a separate file.

Usually, softwares fetch the image from file itself in priority, if none is found, they will then try to find a cover.jpg or folder.jpg file in the folder.

But some softwares don’t manage both metadata images or separate files, only one type.

7 Likes

Also remember to turn on Hidden Files on your OS file system. Media Players like “Windows Media Players” and the MS OS hide these image files.

Also realise that where you play your music changes what you see. Many media players act totally different. Some want cover.jpg, some want folder.jpg, some want embedded artwork. Something like iTunes makes a totally separate set of folders to store art in alongside the albums.

Your NAS may be keeping a separate database of artwork. I use KODI and it makes a database of art and options allow it to ignore the art in your files and just pull in new artwork from the internet instead. It is all about settings in media players.

Use a tool like Picard or MP3TAG to inspect your files. That will show you which has embedded artwork.

1 Like

yes. It is part of the format defined for mp3s

Everything you have described indicates that it is. Note that the size of the artwork can be small so there will be no clear indication from the size of the file if it contains embedded artwork.

Use a program such as foobar or tag&rename to confirm that it is in the file or not.

The other files (folder.jpg etc) in the folders may be confusing the issue. When you browse a folder (directory) the folder browser will may display that image, but when you play an mp3 file the embedded artwork should be displayed. If you use a program such as those suggested you can easily check that the artwork is there and what it looks like.

If there is no artwork embedded in the mp3 file, then some players will use other files such as cover.jpg or look up a cover in their own database (eg itunes). This behaviour varies by player so playing the same file with no embedded artwork may have different results if you use different players such on your wife’s car.

1 Like

Ok that is really helpful, thanks everyone.

Is there a loosely ‘cover-every-case’ art work arrangement? I have one person on android, one on iphone, one on win11, I am using macos (and ubuntu desktop) and android and the shared kitchen rpi moode player is a linux box serving a web page. Having a ‘works on most devices, most the time’ would be really useful target to aim for. Something like album thumbnails in meta for all tracks in the album folder and then a higher res folder.jpg in the folder?

Given the priority, would this mean it scoops up a thumbnail from the meta if looking for the main image, if there is no main image in the meta, but instead as a ‘folder.jpg’? So would you put a main and a thumbnail image in a track metadata? (as in can you/ would you put 2 images in?) and would you do this for every track on the file? (my idea is not space economic is it?)

1 Like

There is not really an “every case” solution… but embedded artwork is likely to be the most flexible “works on most devices most of the time”. This is going to use more file space but modern devices usually have lots of space so is less of a concern.

Personally I don’t embed just due to file size and my use case I find a single cover.jpg in the album folder works fine. My android wants cover.jpg, the old blackberry wanted folder.jpg. My media centre reads cover.jpg and stores it in a database.

It is the classic problem of “standards”… no one agrees.

Some media players will set a priority - using a cover.jpg to override embedded if found.

Your best bet is a test. Get an album with embedded artwork, and stick a different image alongside as a cover.jpg. Then see what each device does with that simple test case.

Just remember - if you are using embedded, then embed in all tracks.

And I don’t bother with “main and thumbnail”. Just a single cover.jpg to cover both cases.

1 Like

What music player app is your iPhone user using? - the standard music app loaded via iTunes or something else?

It is my mum, she is a guest, I will check when she comes back. Probably the default. I play on the phone from androin on a file explorer called cx file explorer. Not heard any thing bad about it have you?

1 Like

This is an excellent start - and something Picard will do out of the box with the right cover art settings enabled.

I would do this for a couple of albums, see how you go with all your devices/players, and then you can tackle edge cases if they come up.

If you do it using Picard (you may have to add artwork to musicbrainz where it’s missing or crap) it’s easy to do another pass with different cover art settings. Everything will already be matched and you just have to hit ‘save’ with the new settings enabled.

At the expense of storage space, yes… :slight_smile:

It all depends on your music players…

itunes only uses the embedded cover image in the mp3 files. It can range from small (160x160 pixels) to BIG (4000 x 4000). These are loaded into its database. When the track is displayed on the iphone, the artwork is small. I don’t know if it is rescaled to fit the phone when it’s synced to the phone or when the phone displays it.

I assume your rpi moode player has a TV or bigger display than the phones you have… If so, the question is how does it handle the display of artwork for a track?

  • If you put a small image (160 x 160 say) in the mp3 file, does it look bad?
  • What size image do you need to put in the mp3 file for it to look good or great?

If it needs to be big - say 1000x1000 to look good on your web page/TV, then you have two choices

  1. Embed 1000 x 1000 images in every mp3 file so it looks good on the TV and hope it all fits on the phones.
  2. Have two separate sets of folders/files: one for the phones with small embedded images and another for the rpi moode player etc where you have big images.

Choice 2 requires maintaining two or more set of ‘output’ folders. Your diverse set of devices is creating this challenge for you. I have a very similar one, so I can understand that it is often not by choice! There are various tools that can help with resizing images in bulk, but you need to decide if that it the path you want to go down. Lots of people here prefer flac over mp3 as their master copy because is lossless so it sounds better. If this is important to you and you can re-rip your music, you should consider this.

btw, thanks for the mention of the moode audioplayer. I knew of volumio, but not moode. I’m looking at the rpi player land, waiting for prices to come down and maybe the rpi 5 to comeout…

1 Like

No screen. It is headless, but serves a webpage. Just to be clear: pi connected to dac, connected to old upcycled lowfi player in the kitchen. No head. You browse to the.correct.ip.address from any device that can, phone, pad, laptop, desktop 2 rooms away and you get the pretty web front end, local only. Use the web page to pick a song, an album, and press play, and it plays in the kitchen. From my phone standing in the shed I can tell the kitchen to play [song name here], then from the web browser on the laptop in the bedroom I can change it again.

Seems the Music brainz 500*500 standard format comes in at 10kb, not too big and not too ugly. Happy medium? Not tried it on the web browser on the 4K smart LG WebOs tv. Might change my mind if it see it…

Moode, yes I spent some time reading about rpi players, my (IT professional) bro swears by openelec. I am having a look at Jellyfin for the TV for streaming nas based DVD content. Seems I could run it as an app on the webOs LG or put it on a pi4, and pipe that into an hdmi. I would have either streaming from the NAS as that is where all the disc space is.

Talking of space, yes I was tempted by flac, but then space use? and does it stream to all players? I did not think flac was universal. Am I wrong, it has been some time since I read about this?

RPi boss and founder says no rpi5 in 2023. I have heard good things about odroid.

2 Likes

Disc space is getting cheaper all the time, and FLAC support is getting much more common. You’ll find it in all the RPi players, Android kit, modern car stereos, etc. Also if you are connected to real speakers then you’ll hear the difference from MP3.

I run a KODI media centre for that same excuse of pushing it around the house on multiple speakers. Or play direct through the web browser. Yatse App on the Android phone links to it well, and also acts as a good local player for the phone. Currently the KODI system is a PC but likely to change to a Pi in the future.

There’s no Musicbrainz standard of 500x500.It all depends what is uploaded. Artwork can be grabbed from many places. (⎌Picard can help with this).

Regardless, you only care about displaying on your phone, 500x500 is massively too big and wastes space on the phones so, you should be embedding smaller size images into each mp3, but if you ever want to display it on a HDTV or even a 4K It’s not going to look great! I was saving at 300x300, but then I saw how bad it looks…

I agree with @IvanDobsky, storage space is getting cheaper all time and I’m planning to be displaying on a large screen as well as phone, so I’m collecting large resolution artwork and creating two sets of music files. One with 200x200 for the phones and the other one with large images (1600x1600 or higher if possible) for TV or computer screens.The 200x200s are created by resizing the large images. I want to get the files fixed for the future…

In the end it comes down to what you want…my plans changed,so,I’m trying to keep my options open even if it takes more space on my server.

As for flac, it is preferred because I can generate mp3s for the car or phone with low quality and still have high quality music at home. You can’t get as good results going the other way…

1 Like

I don’t know what your phone is, but even my old thing has much higher res than 500x500. I would never use images below 1000x1000. 4K phones are pretty standard now. Plan for future, not yesterday. Otherwise you only have to do it all again. (I’ve Been there, Done that… those wasted years ripping all my CDs to MP3 only to change the HiFI and have to start again with FLAC)

This is Truth… it is trivial quick to punch a script to bulk convert. Don’t build a collection around the lowest common denominator. But it is also just as quick to get a FLAC player for the car. And I have now got to the point of just using the phone to play FLAC in the car anyway…

The main rule - don’t plan for today, plan for tomorrow. Today’s kit is already obsolete.

500x500 is one of the standard sizes available from the CAA via MB. For me, this is plenty big enough for devices I use, and doesn’t significantly increase the size of a high quality MP3. But yeah, might not look great on a big screen.

1 Like

My entire phone screen is 1920-by-1080-pixel resolution at 401 ppi. No idea of how much of that is used to display the cover art by the Apple music player and the other music players I tried. I did build a set of MP3’s with 2 or 3k images, but I realised was that I don’t look at my phone artwork in any detail. If I’m driving, yes I’m listening to music but I’m actually looking at the road or glancing at Google maps. Same for walking. So I don’t really need high resolution art on the phone. If I’m on the train, then maybe I’d look at, but really I’d want to look at back of the cd and the booklet. That’s a goal and quest but I haven’t found a music player that will let me display and browse those.

I use cuetools to do my bulk converting. You just set the max size and click go.

I have foobar2000 on my iPhone which plays flacs. I assume it’s available on android phones, but AFIK, It doesn’t work with Apple car play and Siri which is a requirement for me, hence using the Apple player - which is getting worse with each release.

You are correct. My mistake.

The standard sizes look a bit antiquated. iTunes recommends 3000x3000, Spotify 1600 x 1600 etc. Probably need to be updated…

I would do a large image in the album folder as cover.jpg or folder.jpg, and then if you have to embed images for a player (usually mobile or something) I would also embed a low quality file in the tags. Should be pretty straightforward with Picard.

Then your only concern then is setting your ‘good’/bigger screen players to use the image in the folder instead of the ones in the tags, so you’re not burdened with crap ones everywhere.

1 Like

Would work, and would be convenient but many would argue a player that does that is not compliant with the spec. That would not be the first time!

Another approach that has not been mentioned is to simply stream the music to the phone and not care about storage on the phone. One of the youtube videos on a raspberry pi based music server that watched mentioned this. My current EE plan has 200gb of data transfer that I barely use….

I am like @aerozol - I never embed. Only use a single cover.jpg image in folders.

This is most certainly “compliant with the spec”. Media players have always picked up cover.jpg or folder.jpg. It is only really Apple and their “special” standards that break this spec. :laughing:

I just copy\paste folders of FLACs from my NAS onto the android phone or a memory stick. The cheap head unit in the car does not display art, just reads the FLAC tags. Lately I have more swapped to using Yatse on the phone and connect to an audio jack. Easier to select music on the phone screen.

The key is stay flexible. Don’t commit to just one system.

I have an allergy to seeing pixelated art on a phone. So use the exact same 3000x3000 scans that are on the media centre. Can’t be bothered to waste time converting anything.

As to streaming… funny you say that. I have started experimenting with streaming from my home KODI system, via a VPN, to the phone… but then I am an anti-social git who don’t do these social media driven digital stores. The main concern I would have with streaming on a phone is on a long drive you’ll be dropping in and out of signal strength.

1 Like

The mp3 tagging spec id3 is orientated to a single audio file, not a ‘album’ or collection of tracks. I believe the flac/vorbis one is as well. Neither say anything about how to display the album artwork and conventions for folder.jpg or cover.jpg. Is there a section I missed?

Both id3 and flac specify a standard list of artwork types for embedded images. Are you suggesting that a player which ignores an embedded image of the ‘cover’ type and instead displays cover.jpg / folder.jpg is not ignoring that part of the spec?

They ignore folder.jpg and cover.jpg and adhere to the track specific cover artwork per the spec. So I think that’s unfair or are you referring to something else?