I think I now understand the behaviour.
On the General tab is Artist Name and Sort As (= album artist I suspect).
I think it is these fields Audirvana is using to overwrite the audio files.
I may even have been unlucky (I tagged Abba, Audirvana uses ABBA, hence it was an update).
Either way, I will not be using this artist picture feature. It is too risky!
I think I now understand the behaviour.
@Graham_G: yes, @Doudou has a point. Audrivana is actually explicit about what happens to local files after metadata analysis or manual edits depending on whether the Metadata Recovery switch is On/Off.
Here is the statement:
I only embed the album cover artwork in the music file, preferring to keep all other artwork in external jpegs, etc. I am disappointed that Studio wants to write the artwork to the music file – Studio should give you the option to store the artwork outside the music file. Neither Roon nor JRiver Media Center store the artist pictures in the music file.
@Doudou @AndyLubke: I just started the trail for Audrivana Studio (ADS) on Mac, but have lots of experience with other players and meta editors. I thought this might be a good place to ask some metadata (MD) related questions:
- Can ADS access local MD stored in album folders?
Example: an image file named cover.jpg for the album artwork
- I realize ADS creates a default album name (based on the folder’s name), but will this take priority over the embedded album name when it displays that music.
Example: I have several unreleased remixes/bootlegs for an artist, which have embedded Album tag the same as the Title tag. However, for file management purposes, I have grouped them into a Remixes & Bootlegs subfolder under the Artist. The embedded Album files end up as singles, and the unembedded files take the Remixes & Bootlegs name of the subfolder.
“The software only creates a default album name (using the name of the album folder). Every change you manually make is saved both in the Audirvana database and in the original file, making it much easier for you to preserve your audio files and their related information.”
I much prefer any changes I make in Studio to be saved only in the Audirvana database, not in the original file – just like Roon.
I don’t think the Audirvana team is treating music files like the digital assets that they are.
I actually go one step further and say that embedding the cover art into files is also just a waste of space/time. When you embed an album cover into all 10 tracks of an album, 9 of them are sitting there for no reason. Many media players will stop as soon as they see the first one.
I always prefer to provide the cover.jpg file inside each album.
I don’t know why Music Players don’t allow you to provide all other images (like Artist images) this way. That’s how most Video players have been doing it for over a decade. Just create a file naming scheme and require the image files to be at the Artist or Album folder level based on the type of image.
Yes it would be preferable to have the option to chose, but I think the intention here is if you were to make a large universal change to an entire album and would like those changes to reflect in another Music Player accessing that same folder.
What you say makes good sense. I also keep the album cover artwork as a jpeg file in addition to embedding it in the music file. It would make sense to stop embedding it in the music file but I have always done this.
Yeah its definitely only a habit I picked up over the last year. I am really only strict about it with lossless / uncompressed files. If an MP3 download comes prembedded from soundcloud or something, I will usually let it stay.
Actually, I use AS only with some 20 albums in order to try its sound quality. So I didn’t dig any further into its behavior regarding metadata. But previous Audirvana players recognized a jpg file in the folder of the album that was named “cover.jpg” or “Front.jpg” as the cover of the album.
I actually prefer the album cover to be embedded in the metadata. That way it “travels” with the files, when for example you make compilations for mobile/in car use.
Agreed. I was thinking the same.
That’s what I do also. Maybe a past habit of long years in which iTunes was the only player.
Please note I was talking about ARTIST image when I opened this topic.
Not album cover. I also embed that in the files.
I absolutely agree.
Personal digital assets should not be altered without specific permission.
The players that I use on Mac do not have the option to add Artist image. Audirvana players did not have it too, and this is something new in AS. (A2.5 did not have this option. I think that A3.5 neither.)
I don’t think AS is embedding the artist image.
What I came across was (I think) a side effect because (for example) I had tracks tagged as Abba and AS updated them to ABBA whilst I was adding an artist image to the AS database.
This side effect is a bug that seems to exist also in previous Audirvana players. I use A3.5 for a few days and I loaded to it a significant part of my library (BTW, it does it quickly without the endless analysis of AS.) And A3.5 displays very strange metadata for some albums and artists. For instance for some artists, it displays the name of the folder in which the albums are in the registery, such as “ROCK FLAC”, as being the name of the artist of the album.
If you have a cue file in the folder of the album, in which the name of the artist is “ABBA”, AS may choose it as the name of the album artist.
The same bug in A3.5. It displays in capital letters the name of a group that is not tagged that way. There’s no cue file in the folder of the album with the name of the artist in capital letters. So why A3.5 does it?
It’s a legacy bug that AS inherited.
I agree with you.
As far as I am aware, all music players worth their salt can deal with embedded cover art work. Some can as well deal with associated files as described by eyeala.
However, the naming convention for the associated files is not always consistent from one application to the next.
For example, some will accept folder.jpg, others will expect cover.jpg.