Understanding Year of series and issue

Trying to get my head around the year data CT produces i.e. from ComicVine.

It was my understanding that the "norm" was to use the year of the first issue of the series.

For example:

http://www.comicvine.com/farscape/4050-29919/

Would be Farscape (2009)

However when I tag issues no where in CT do i see the 2009 year. In fact i only see the year of the issue release i.e. 2010, 2011 etc.

Are we not expected to use the series year (i.e. issue #1) as part of the true series identifier anymore? Or is this part of a bigger more complicated discussion?

I believe that it is the year that each actual issue was published... sucks in some ways, but actually makes sense once I got used to it.

The "Year" and "Date" text fields in ComicTagger are populated from the Comic Vine's "cover_date" field. (Before the recent changes is used the "publish_year" and "publish_month" fields). Comic Vine also now has a "store_date" field. The "cover_date" is the date that appears on the cover or indicia of the comic issue. The store date is the actual date the comic was on sale. For historical reasons Marvel and DC have cover dates a few months in the future.

Comic Vine also has a "start_year" field which is the year the series started. There is an option in CT to use the "start_year" as the volume number.

As far as I have seen, the general standard naming for CBRs is:

Code:

_SeriesName_ v_Volume_ _IssueNumber_ (of #_Count_) (_Year_)  (_Other_Stuff_)

When trying to parse (read in) filenames to get tagging info, this is more or less the template that CT expects. It's not very easy to always reliably parse filenames, as it's often quite hard to figure out where the series name ends and where the issue number begins. ("DP 7 3"). Personally, I prefer to always have the "#" in front of the issue number.

You can always change the rename template to be whatever you want, but CT might not be able to re-parse the data in the absence of internal tags.

Thanks for the replies. Being Captain obvious for a second... the problem is that names seen in the wild follow no true naming standard. I find it hard to believe none was ever written down but as far as I can tell they havent.

I had a quick look at it seems that the year in the name should be the "start year" and often is. Unfortunately it is often the issue year and with no marker to indicate which scheme was used.

My driver is for creating a neat filing system (folders) and not actually file renaming. Once CT has tagged an issue with metadata the filename is not that relevant to me any more (this is a good thing).

I would like to be able to save the "start year" into all issue metadata. This would allow me to file things away using this scheme (example):

Code:


/store/Fables (2002)/
..Fables #001.cbz
..Fables #124.cbz


However if i use the issue year (th information currently available) this would be:

Code:


/store/Fables (2002)/
..Fables #001.cbz
/store/Fables (2012)/
..Fables #124.cbz


in essence i would have over a dozen folders for one series when obviously it should be only one. Another major downside if this issue year approach is that it is easy to cite examples of duplicate folder names.

I am certain there will be exceptions but in general this statement should be true:

"On top of issue specific meta data, we should have series, volume and start year saved per issue"

Hopefully i make some sense

The only time I ever see the start year in the file name is when it appears *before* the issue number but after the series name, where a volume number might be. When a year appears *after* the issue number, it's always the date of the issue, at least in my experience. And, yeah, it's unfortunate the ICFNCBDF (International Committee for Naming Comic Book Digital Files) doesn't exist, so we have to muddle through the best we can. :-)

When I made ComicTagger I decided up front that I wasn't going to create a new tagging standard, or modify the existing ones. My goal was to only implement the existing ones, to promote tagging in general. Unfortunately, with respect the problem you're having, none of the metadata schemes that I implement have a "start year" field, but all of them do have a "volume number". On the flip side, the Comic Vine database doesn't have a "volume number" field, but does have "start year". D'oh! Both the CBL and CR schemes *are* extensible, and could hold extra custom fields, and maybe at some point I will consider adding a "start year" field, but currently I'm still philosophically opposed to adding fields that no other reader can recognize.

At the moment, the best solution I can offer is to check "Use Series Start Date as Volume" in the preferences/settings dialog (under "Comic Vine" tab). This will, for example fill in "2002" into the "Volume" field in CT when you get get info from Comic Vine. You, will however, lose any sequential volume numbers that might have been parsed from the original volume number.

Thanks for the detailed reply. Everything you say is completely sensible. I/we have to resist the futile temptation to try to beat the world into submission to do things right.

If there is one thing I am not sure I agree with it is not storing all available information due to some 3rd party limitation e.g. schema. This is doubly true if the schema is naturally expandable.

I understand that adding random metadata to say ComicInfo.xml will not magically result in this data showing up in Comic Rack however the process of sourcing this data is relatively costly in terms of computer, human and Comic Vine time. There should be some means whereby no information is discarded and all is saved (or at least that option exists).

Personally I don't mind at all extending the CR schema that is what it is there for. I would rather this than have to scrape CV again xxx thousand times if CV adds more fields in the future.

I say serious consideration should be given to pushing this whole area a bit further and dragging CR etc with us. As long as we dont break backwards compatibility I can see only good things coming from it.

Like I said, I'll think about it.

In the meantime, feel free to chime in here and here where I posted some requests relevant to this discussion.