Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[newbeet]

I have been trying Media Center 16.0.111 since yesterday.  Changing tag information on MP3 files ALSO changes their dates under Windows Explorer's "Date Modified" column--athough the size of any such file did not change!

Although the original MP3 files' date stamps are preserved inside the tags, it's important for some people to keep each original WINDOWS date stamp.  My files migrate onto different computers and I need to keep track of original dates for a few reasons.  Some users may or may not care, so it would be quite convenient to allow those who do care to stop MC from changing original dates.

For references:

1. The audio library software that comes with Creative Labs sound cards (Creative MediaSource) leaves file stamps intact after changing tag information. 
2. The encrypting software TRUECRIPT gives you the option to leave file stamps unchanged, however significant the content change within the file.

I went through MC's Tools|Options carefully. I did not see such an option.

Are you interested to add it? Very soon? 

[MC is a QUITE capable software, although its way of producing panes from one moment to the next is still unpredictable to me (after an evening of fooling around with it.]

[JimH]

You might want to download the build from our download page.  It's 121.

There are several Windows dates, but if you change the tags, and you're storing tags in the files (optional), then the files have been modified, so it would be incorrect to leave the date unchanged.

[newbeet]

Are you saying that it is optional to put a tag in a file in MC?  Where would that option be?

[MrC]

I think you're asking if you can prevent tags from being changed when you change MC's database.

Edit->Update Tags When File Info Changes

You can also control which tags are written to files under Options->Library & Folders->Manage Library Fields.  There is a check box for "Store in file tags (when possible)" on a per-tag basis.  But since you'd probably want to disable all the tags that are written (and hence change the file's timestamp), the above method is probably what you want.

[newbeet]

MrC, I was misunderstood: I want updated tags.  But it's more important for me to track a RECORDING DATE than the latest tag update.

JimH, I am aware of your logic.  Here is my last go at explaining my request. 

If a music file has 2 components, A (for music) and B (for tag), it would be IDEAL for an operating system to track the dates of A and B separately.  But Windows does not allow that.  So, the typical software deals with date stamps by following the most logically obvious route: the file date stamp changes as soon as any file component (A or B) changes.  Fine.  But some customers are MORE interested in tracking A's date, more than date changes due to changing B.  And I say: give them that option--as other software have done.  How?  Make it optional for the file's date stamp to be just that of A.  The alternative--albeit more stylistically logical--is not only comparatively insignificant to such users; it really screws how they manage their files on multiple computers with different software. (The exact sequence of recording dates is important to me and, therefore, must stay the same regarding of the computer I am using; so MC16 on 1 computer would be messing how I deal with other computers.)

Obviously, meeting customer needs must not cause software malfunction.  No problem: other software have offered that file stamp option without malfunctioning.  Is it not wise (commercially anyway), then, to offer choices rather than straightjackets?  MC16 already has an array of detailed options, so this request would just add one to the bunch.

[flac.rules]

This seems like a higly spesified request, that is only useful for few people(?). Is it possible for you to use one of the prgrams that allows you to change data-information in windows to just set "date modiefied" back to "date created" afterwards?

[MrHaugen]

If a music file has 2 components, A (for music) and B (for tag), it would be IDEAL for an operating system to track the dates of A and B separately.

No. Windows do not do that. But unless you are a musician that have to actually edit the music after creating, I do not see the big problem of using windows' date system? Date created will tell you the date of the music it self, and Date modified will tell you of the latest tag changes. I fail to understand why this is a big problem. Perhaps the date created will change when you copy the files, but there is apps to change this dates I believe.

[Mr ChriZ]

Are you keeping multiple copies of the same file?
If so it maybe easier to track by writing the date into the file name.
That way you don't have to go into a files properties or have a detailed view to find out what version it is.

Just an idea...

[MrHaugen]

Or, you could add a custom date field in your library perhaps? The copy tool might help you easily copy the initial dates before you start messing around.

[newbeet]

First, thanks all for chiming in.

So, the problem was to preserve the recording date rather than the ephemeral date stamps of the latest tag changes.  Now, toward a solution. 

First, as mentioned in the initial post, the software bundled with Creative Labs sound cards solves that problem.  It does it by default.  That software is an above-average manager of audio libraries. It reminds me of MC, though MC is generally better at customization.  But CL's software ties you to computers with CL cards.  [I believe CL now sells a stand-alone version of that software.  Something to investigate.]

A second option is MP3tag, a donationware tag editor found on this German site, http://www.mp3tag.de/en/.   It offers precisely the option I was looking for in TOOLS | OPTIONS | TAGS.  Click the box titled "Preserve file modification time when saving tags."   I wouldn't quite phrase it like that, but it does what I want.  You change a tag information, yet the file's "date modified" does not change in Windows Explorer.  Although MP3tag specializes in the tag business, it can also create playlists.  It can play a file by calling VLC.  It displays by default some 18 fields, but you can ask it to display an extended list.  You can also create your own fields.

So, MP3tag obviates MC's tag editiing capabilities.  But there is still a hurdle.  Using MP3tag together with MC is cumbersome: do all tagging operations in MP3tag to preserve recordiing time structures, then import the whole file set in MC as a database each time you make significant tag changes outside MC.  If MC updated its database AUTOMATICALLY in response to EXTERNAL tag changes (performed by MP3tag, for instance), then it would automatically update tag changes in its database.  But MC does not seem to do that..

Still looking.

[MrC]

...  If MC updated its database AUTOMATICALLY in response to EXTERNAL tag changes (performed by MP3tag, for instance), then it would automatically update tag changes in its database.  But MC does not seem to do that..

I believe this would create a race condition.  MP3tag is updating a file, the file's last write timestamp is updated, MC is notified that a change occurred and it starts reading the file... before MP3tag has completed its processing.

[newbeet]

Things are not as bad as I thought.  From a tip in another tthread in this forum, I tried the MC commands

 TOOLS | LIBRARY TOOLS | UPDATE LIBRARY (from tags)

MC imported the tag changes made by MP3tag into its database!  This means 2 good news.

1.  No need to keep importing databases into MC just because of external tag modifications.   Just UPDATING MC's database does the job.
2.  MC imported an EXTERNAL tag change without changing the file's date stamps!!! Apparently, tag changes from INSIDE MC change date stamps, but not OUTSIDE tag changes!

So, working with both software is not as forbidding as I thought, if I do all my tag changes from outside MC.  But it's still ridiculous to use 2 software to do the trick.  

To JRiver: take a page from the humble MP3tag: offer the OPTION to insulate the date stamp from tag changes.

[EdBrady]

To JRiver: take a page from the humble MP3tag: offer the OPTION to insulate the date stamp from tag changes.

I'd like to see this option also... it is fairly common in programs that allow editing of tags.  There are those who prefer that the file's date/time stamp not change when only the tag info changes.

[MrHaugen]

As others have mentioned, this behavior is part of the way MC works. It relies on this modified dates, to look for changes (I think). Would it be wrong to have an option to preserve the modified date? No, but it would force J River to change quite a few things I think. And would they do that for such a small part of the user base this question really concerns? I don't think they will.

My question still stands. Is it really not possible to use other Library fields or the date created field for this purpose? To keep record of the actual recording dates? You HAVE to use the modified date because of other programs or what?

[newbeet]

MrHaugen,

Why don't I keep the recording date in a tag field?  I need to keep recording dates consistent over a few computers, some without MC. A single machine using MC16 must not force undesirable tag-dictated date changes all over the place. Now, any single modification under dozens of tag fields changes a date. Though logical in one respect, that change is practically MEANINGless.  Soon, I won't remember whether it was due to the correction of a minute spelling error in a title or to my incessant rating flipflops. These are non-events relative to the coherent story told by recording dates. I want to remember what I recorded in 2005 versus 2009. Storing these records in an MC database would make MC a central archive. I don't even use MC everywhere. That would be crazy. The ubiquitous OSes are more convenient time keepers.

All that stuff will sound unimportant to some, especially if they don't give a darn about file dates. We are different, which is why software have the OPTIONS command. The tremendous granularity of MC's options offers a strong hint that its developers understand user differences. The date stamp option is in the spirit of MC's granularity.  It might even be on their to-do list.

My question for you is, since many software offer that option, why do you think it would add sand in MC's oil? It may be tough to answer that one. So if you don't, I'll understand.

[MrHaugen]

Ok. I understand the problem, and I see your point.

MC have the option to look for, and update, files with updated content or tags. If this modified field would stay unchanged, MC would not have any idea when to update the library. To do this as a default and only behavior would be less good. For most.... But as an option would be ok. An alternative way of updating tags without modifying the date. The update on external changes would have to be disabled in this case I think. If external changes should be picked up, I don't see many other ways than to scan tags at an interval.

I'm not sure whether this would affect other things in MC. If it does, it could be quite the job. Or perhaps it would be a very trivial task. I would not oppose such an option though. I would just not like much development time being spent, when there is much more pressing improvements waiting, that would affect a much wider audience

[BartMan01]

When I need specific dates tracked for files, I include them in the file name.  I have never trusted the OS with date fields, have had way to many unexpected things happen there.  I just make my file names:
YYYY-MM-DD Filename.ext

I know that doesn't answer your current question, but something to think about in your workflow.

[MrC]

While maintaining the modified date is a useful option to some (and I'd argue to those who don't care about time stamps),  I think, Newbeet, you might be overstating the case a fair bit.  It is rare to find software that goes to extraordinary measures to avoid affecting a file's modified date.  In fact, the very semantics of a file's modified date is just that - the file has been modified.  While it may seem to you that a case should be made for *minor* modifications, the change can also affect other software inadvertently (such as backup, sync or other any other software that relies on updating internal databases after a file has changed).  Really what you're asking is to move the semantics of file meta-data into, and managed by, the file system.  Where does one draw the line?  If I change some obscure, non-content affecting meta-data in a Word document, should Microsoft Word also provide the ability to not update the .doc's modified time stamp?  Or how about a Thunderbird calendar, when the only change might have been to dismiss an alarm?  Or an Excel document to change one digit not affecting any calculation?

If a change is "MEANINGless", perhaps it is best not to make the change.  Otherwise, you'll have to remember which files to backup too, since you can't rely on modified dates.  It sounds more like your approach is to blast-copy all your files from computer to computer, rather than used change-based or time-based copies.  Perhaps there is a better method.

MC doesn't have to be your central database; as MrHaugen has indicated, you can certainly write your own date tags into the files, and that way, ensure you have this data regardless of underlying file systems or operating systems.

Unless you're running an AD server, or maintain network-wide time via something like NTP, your system times are likely to be out of sync anyway.  Timestamps under these conditions are gross-level at best.

So while I appreciate the request for desired behavior, keep in mind it is just one of a very long list of requests, and its implementation in general is the rare exception.  There's your sand.

[newbeet]

MrHaugen, I suspect the job is not very difficult. Others did it years ago.  The easiest scenario is when the user modifies a tag WITHIN MC.  MC should then update the database. No problem here. If the tag change occurs through another software, then you detect change with the "archive bit", the date modified change, or--why not--by scanning the meta tag for a meta tag signature change. There may be other ways. Don't discount my request as super-ethereal. I already mentioned 3 software that implemented the idea.  Creative Labs' MediaSource implements it by default. Some people have been thinking along those lines.

Bartman01 and Mr Chriz, thanks for the idea of writing the date in the filename.  I used that trick years ago for something else. It's reliable, but it's a brute force method when you apply it to thousands of files. It also leaves less room to maneuver when you have to sort.  If the date is at the beginning of the file name, then you can no longer sort for the real names that the files would have otherwise had.  If the date is written elsewhere, then you can't sort on dates.  As one of you said, it's an idea, but I hope it's the last resort.  I think bringing MP3tag into the picture is already a big step ahead for what I want to do (MP3tag has a misleading name, because it does not just do MP3 tags).  As I shop for that feature, I hope to find more of such programs.

MrC, discussing with you is tough.  The stuff about what is correct and where to draw the line is totally irrelevant.  Meditate on the word "option".  You don't worry about how users will back up if they CHOOSE to bypass the software's default.  What happens to their backups is their problem, which is what happens to people who choose to leave any beaten path.  Users who think like you and users who don't care about date changes simply stay with the default.


For me, the thread has served its purpose.  While trying MC16, I found a desirable feature lacking and made a push for it here.  Feedback seems to be that the MC team has more pressing matters to deal with than this particular issue, which is understandable.  So I turn the corner on this issue here.  Thanks for thinking along with me.