Year By Track

[PepsiCan]

Re: Year By Track

The ID3 tags are standardized by id3.org. They have a list of contributors and links to contact them on their webpage.

For FLAC, the standard is set by xiph.org. Not sure how they handle feature requests, but they do have a bug report link.

ID3v2 supports multiple year tags. It has one (YEAR) for the issue date of the record and ORIGYEAR for the original release year of a track. FLAC has no metadata standard. You can pretty much define your tags as you like them and add additional ones as much as you want.

The issue is therefore not the music, but the application. I think what needs to happen is for additional meta fields to be added to the "Review Metadata" screen.

[schmidj]

Re: Year By Track

Having worked for many, many years on various standards committees, or groups filing comments or making suggestions to standards committees, the nonprofits, such as those below, often have organized procedures for suggestion or proposal of changes. If the standard is actually adopted by one of the world standards organizations as a true standard, they are required to have such a system or they are at risk of antitrust prosecution. Most standard setting organizations are very happy to have new blood to work on improving their standards.

Proprietary standards, such as those dreamed up by Microsoft, Apple, Sony or such, that's a different story. Good luck, unless you are a large corporation like my former employer (I'm retired now), and can use your purchasing power to influence their direction (money talks!) That's why there are the FLACs of the world, to do better without the influence of large corporate business models. And many of these large corporations, including my former employer, do strongly support the nonprofit open standards efforts, because most things in the world work better when standards are available to foster interoperation between devices.

The ID3 tags are standardized by id3.org. They have a list of contributors and links to contact them on their webpage.

For FLAC, the standard is set by xiph.org. Not sure how they handle feature requests, but they do have a bug report link.

MusicBrainz is also a nonprofit, and is run by metabrainz.org. They do have a contact page, so might be open to suggestions. While their software, Picard, works well, the database interface to dBPoweramp has an issue and keeps hanging.

Freedb is a lost cause, if you want any level of detail. They have quantity, not quality. Look at their raw database entries on the web. Very little info, not even composers.

I will agree that many of the commercial software products and databases are sorely lacking either in performance or user friendliness. For the most part, dBPoweramp is an outstanding exception.

The issue of software interfaces and performance extends very much to the audio and music editing software business as well. Some software performs well musically with good audio quality but has a miserable user interface, other has a nice user interface but doesn't do what you need audio or music wise. In the days of analog audio hardware, the successful products sounded good, worked well, and had simple controls that any audio engineer or musician could figure out without an instruction manual. Sadly, that has become lost.

[BrodyBoy]

Re: Year By Track

Perhaps the standards people should set one tag as "recording year" and another as "release year".

And therein lies the rub....

Whether we're talking about metadata provided by publishers, library management tools designed by software engineers, or the collective preferences of end users, there aren't really any "standards people." It's kind of the "original sin" of digital music, and it's probably the reason for about 80% of the discussion on forums like this one. :(

[PepsiCan]

Re: Year By Track

Perhaps the standards people should set one tag as "recording year" and another as "release year".

And doing so would also resolve the issue of re-releases of old albums. Did you know that Bohemian Rhapsody was apparently recorded in 1993? It wasn't. But that is when they did a remaster of the 1975 album. :-)

[schmidj]

Re: Year By Track

Brody,

I'm not surprised there is an issue with players. But my point to Spoon is that it should be my choice on how to store my years and genres, not an arbitrary change made by dBPoweramp because I happen to open a particular window for a totally different reason. As I'm sure most of us are aware, although many of the databases may only have one value per album, on my server all metadata is stored per track, not per album.

Unfortunately the people writing much of the player software don't think this stuff out very well. The making of a particular album should be the album title, the album artist and the compilation flag, if it is one, not anything else. Now i realize this may turn out to be an issue with artists who have more than one "greatest hits" album. Perhaps the standards people should set one tag as "recording year" and another as "release year". I'm hoping the new version of Foobar, which Spoon is supposed to be involved in, is better in this regard, but I also need a better front end for it on my computer, dragging and dropping isn't very convenient.

[BrodyBoy]

Re: Year By Track

The issue with the ripper is that if you open the "review metadata" screen after you have entered track-by-track years or genres, the dBPoweramp software replaces them all with (I think) the value for the first track, even if you don't change the settings for year or genre on the review metadata screen. I find this one of the few major annoyances in what is otherwise excellent, well thought out software.

Yeah, I get that....that was kind of the point of the thread. PepsiCan responded to my post, however, in which I was explaining why a completely separate issue (players that get tripped up by different YEAR tags on an album) has lead me to prefer the same YEAR on all tracks.

[schmidj]

Re: Year By Track

The issue with the ripper is that if you open the "review metadata" screen after you have entered track-by-track years or genres, the dBPoweramp software replaces them all with (I think) the value for the first track, even if you don't change the settings for year or genre on the review metadata screen. I find this one of the few major annoyances in what is otherwise excellent, well thought out software.

[BrodyBoy]

Re: Year By Track

Right. But then the problem is solvable as there are separate meta fields for both types of information.

Not sure what problem you mean. I was referring to a player issue.

[PepsiCan]

Re: Year By Track

I agree with mville that dBp probably does this in adherence to common use of the YEAR tag to mean the CD release year. For certain kinds of CDs ...usually just big artist retrospective collections, in my case....I populate the ORIGYEAR tag for each track in mp3tag. I prefer the actual YEAR tag to be consistent for an album, as I have occasionally run into players where different YEAR values messed up the ALBUM grouping under certain circumstances. (Probably not a common problem, but a pain when it does.)

Right. But then the problem is solvable as there are separate meta fields for both types of information.

[PepsiCan]

Re: Year By Track

I actually just logged the same request (sorry, missed this one until after I posted). There is a workaround as you can set the release date (and genre) per song in the main screen. But it is not logical. You want all metadata in one screen, not spread out over multiple screens.

[schmidj]

Re: Year By Track

The same issue exists for Genre. If you enter different genres for tracks in the main ripper screen and then open the metadata review screen, it wipes out your genre entries and makes them all the same. I wish this action could be changed. it is mighty annoying, on otherwise excellent software.

[mville]

Re: Year By Track

I certainly hope not. For me, the most important date is the recording date, or lacking that the release date. That way I can listen to music in the correct chronological order. The date of the CD is probably the least important thing going.

I agree. YEAR for my library contains original recording/release date. However, I often have to change this because the YEAR populated by the online metadata database providers, is the CD release date. I manually add a Release Date tag for the CD release date.

The problem for me is always the data provided by the online metadata database providers, it is just too inconsistent.

[Michael Sargent]

Re: Year By Track

... to tagging standards, which probably states that YEAR should contain the CD release year. Hence the behaviour you are seeing. (please don't quote me on this though, as I am not sure)

I certainly hope not. For me, the most important date is the recording date, or lacking that the release date. That way I can listen to music in the correct chronological order. The date of the CD is probably the least important thing going.

Mike

[mville]

Re: Year By Track

There is a checkbox in CD Ripper that offers to force EACH TRACK GENRE THE SAME. I simply see a need to UNFORCE for EACH TRACK YEAR THE SAME. If it stored in the the db cache so I don't have to redo the work, that would be great.

I understand how annoying this. There are similar annoyances in CDRipper, e.g. where CDRipper insists on automatically ticking the Compilation box when the Track Artist varies on a CD, drives me mad. I have requested enhancements to CDRipper many times in the past but they never see the light of day, so I wouldn't hold your breath.

A lot of my help/suggestions are often to get around metadata issues and I realise are not ideal for many end users.

[BrodyBoy]

Re: Year By Track

I agree with mville that dBp probably does this in adherence to common use of the YEAR tag to mean the CD release year. For certain kinds of CDs ...usually just big artist retrospective collections, in my case....I populate the ORIGYEAR tag for each track in mp3tag. I prefer the actual YEAR tag to be consistent for an album, as I have occasionally run into players where different YEAR values messed up the ALBUM grouping under certain circumstances. (Probably not a common problem, but a pain when it does.)