#musicbrainz

has anyone ever run into picard putting data in the id3 tags that says, in the total tracks, "X/X" instead of just "X"?

the data from the site/api seems to say, for example, 26, but picard writes in "26/26"

so if i save something in it and then immediately load it back in, it flags as not fully matched

im going to try updating in a bit, to see if that helps, but otherwise, i have no ideas

Erin: what do you mean by "total tracks"? there is no such field in ID3 as far as i know, total tracks is indicated by X/X in the "track" (TRCK) field

(unlike e.g. Vorbis where total tracks is sometimes stored as TOTALTRACKS)

lw : https://imgur.com/MVLZX2I

left is what was saved

right is what picard brings back from the site

this is post save and reload

do you happen to have 'soxi' installed? (this is part of 'sox' package on most Unix systems) - if so, the output of 'soxi <file>.mp3' might be helpful

i havent added anything and this is windows 10

could you upload one of the MP3s form the album somewhere?

i don't know if there's an easy way to get raw ID3 tags on Windows...

im looking at the spec right now tos ee what's up

i "think" total tracks was an id3v2.4 addition

i am leaning towards this being a Picard issue fwiw, not that it's writing wrong data to tag but it's somehow interpreting the existing tags wrongly

well it sorta isnt writing the wrong "tag" so much as the wrong content

i do not see "total tracks" frame in ID3v2.4 spec https://id3.org/id3v2.4.0-frames

the tag is clearly represented on both sides

there is TRCK frame with "X/Y" (where Y is total tracks") but there's no separate field for total tracks

its just that whatever the site/api sent, that's not what picard put in the field

im not seeing it there either

but not 100% sure what the deal is

picard recognizes it

these /are/ mp3 files

...wait ... is picard acting in flac mode for mp3 tagging?

...is total tracks a flac thing?

that would explain a lot

there is a totaltracks/tracktotal field sometimes used in Vorbis (FLAC) tags, yes

but it's not possible to write that to an ID3 tag unless it was using a TXXX field, which seems unlikely

(that's why i asked for soxi output or a copy of the file, to see what it's actually writing to the mp3)

hm

i don't use MP3 myself so i don't know what it normally does here

checking in a tool i do have

it looks like it's written in extended stuff

it probably writes a lot of TXXX tags for the release id and other mb-specific stuff

as those aren't defined in ID3

...hmm but what mp3tag is showing me isn't what picard is showing me

i think picard is confused about extended stuff it wrote

did it write an extended tag for total tracks though? i would find that surprising

yeah

but what it wrote is /actually/ 26

so it's simply "displaying" 26/26 for some reason

the actual track tag says 2/26, but that's .... valid

but also, it definitely writes them either way, cause that's where all the musicbrainz tags go

what's really weird though is that ive seen it before, but it's usually all the files in an album, or none

this time, it's a few random ones

it's also interesting that picard doesn't write he year tag, seeming to prefer a couple custom fields in the extended section

it should write the year as TDOR for the oldest release in the group and TDRL as the release date... if it doesn't that seems like a bug

it seems to write custom fields called ORIGINALYEAR and ORIGYEAR

(when i say 'should' i just mean that would be the correct behaviour, like i say i don't use mp3 so i'm not sure what it actually does)

right

personally i would have thought it should do that too

.....actually frankly, i thought it _did_

never thought to check until now

does it not write TDRL at all? that would be odd as surely mp3 players expect that

i do have some mp3s lying around, maybe i should load them into picard and see what it does

https://i.imgur.com/1mPc21s.png here's what it did to the standard tags

winamp id3 viewer shows me the same blanks for year, publisher, original artist, copyright

which all seem like things we could have filled out

maybe i really do have to update

so i loaded a random mp3 album into Picard and it hasn't deduced a 'total tracks' field at all https://i.imgur.com/2LKE9w8.png

i wonder if it's something to do with file histories

ah wait no it did

let's see what happens when i save it

it also doesn't happen for me all the time

or at least if it does, it does it without the x/x thing

it did?

if you save and reload, it appears?

it did, i just missed it looking at the screenshot :-)

oh, i see it now

so i saved it, let's try reloading it

right

it ssomewhere else in yours vs mine

ah i think my tag names are listed alphabetically?

anyway ...

when i reload the saves file it shows it as a normal (not green, not yellow) field

yeah, that's good

and to be clear, 98% of the time, that's what happens

it's the few occasions where i save and reload something, it shows me the x / x thing

and indicates a difference at the same time

now, having examined this in mp3tag, it's even weirder, what with the extended stuff not actually having that

begging the question, how has it come to show me 26/26 in total tracks, when what it wrote was .... not that?

or more importantly, when what it read was not that?

definitely gotta update, now

im curious

i just gotta clear though what im working on and then do it

fwiw Mp3tag doesn't show any kind of total tracks field in the resulting file https://i.imgur.com/F1WjleF.png

it does list both ORIGYEAR and ORIGINALYEAR which is a bit odd, i wonder what tags it takes that from

that almost certainly has to be the mb api

or a picard internal thing

that includes you saving after the last screenshot?

i mean, i assume so since i see mb custom tags

yeah, the last screenshot is after saving in Picard and opening the mp3 in mp3tag

but im just ... sort of at a loss

....see im a software engineer, and this makes me want to open the code up now XD

i grabbed a file that didnt have the reload issue in picard and it does still show in mp3tag as having that field

so yeah, no idea

hard to believe that mp3 has been in common use for about 30 years at this point and we're still messing with this

XD

it never ends

mp3 tags are like javascript

(not that Vorbis comments are any better, they can't even agree on what to call the subsubtitle tag)

they weren't meant for this

they were never meant for this

s/subsubtitle/setsubtitle

..............but they were there, and we needed "something" XD

and they got abused and added onto until they became weird

but iwth this being in extended, iw ouldn't even blame this on mp3

i would p ut it on MB or picard

i'm pretty sure it's not mb as the database knows nothing about mp3/id3v2, but it could well be a picard bug

i assume the database just knows the info in general

and the api just returns it

and picard just writes it

yeah, picard is what turns the generic api info into id3 frames

what's even weirder is that the badness doesn't show up in mp3tag

somehow, it wrote 26 into the field, but it reads 26/26

and i dont know how

<11muxxer.exe> Do you guys think that a GamesBrainz is viable?

sure

i don't know if i'd actually use it, but there's loads of metadata people could enter there if they wanted to

<11muxxer.exe> I'd like to try and make such a system, specially given that there is no proper videogame database that is of easy access and to which people can contribute freely.