1. Hi everyone,

    Apple just released Logic Pro 10.5 for MacOS 10.15. We found out that Massive X, Crush Pack, Mod Pack, Replika, and Replika XT will crash.

    Our teams are currently working on a fix, and we hope to have this out to you as soon as we can!

    Best wishes, 
    The NI Team

    Dismiss Notice

Playing a song changes its modification date?

Discussion in 'TRAKTOR PRO / TRAKTOR SCRATCH PRO' started by kimhill, Jun 12, 2011.

  1. kimhill

    kimhill NI Product Owner

    Messages:
    447
  2. Real_Blackroom

    Real_Blackroom Forum Member

    Messages:
    91
    Yes! Traktor updates the played counter everytime. That info is written in the mp3 tags.
     
  3. kimhill

    kimhill NI Product Owner

    Messages:
    447
    Thanks- Just got started with TSP2 and I haven't had a chance to really look into this. But it appears that once the track has been played, a subsequent play does not modify the file, unless I adjust something- like a cue point. It's good to see that the file is not necessarily modified with every play.

    I think the issue is becoming increasingly important now that cloud storage/backup is hitting the mainstream. E.g. with Apple's new iCloud service, music backups will be automatically pushed to the cloud- copying a few hundred MBs of modified files is not necessarily a trivial thing. And then there's iPhones/iPods/portable devices having all modified files replaced.
     
  4. Rob/DJ Sizzly

    Rob/DJ Sizzly Forum Member

    Messages:
    117
    Here's why I think this happens.

    It's not the play count or last played time. This information isn't held in the ID3 tags. What is held in the ID3 tag is the BPM but more importantly the "Date" field which most use as "Release Date". Now, most applications simply use the YYYY format for this field. However, when you play a track in Traktor it updates the date field to DD/MM/YYYY format. Since this changes the actual file the modification date is affected.

    BTW, if the field is in YYYY format then it will update it to 01/01/YYYY.
     
  5. kimhill

    kimhill NI Product Owner

    Messages:
    447
    Rob, other things can be stored in ID3 tags, if a developer chooses to add custom types. Also, I didn't find that my Date tags changed at all, at least as displayed by iTunes.

    I'm pretty sure that the ID3 tags used to store stripes and cue points, as well. Not sure how much they store now in TSP2...
     
  6. Rob/DJ Sizzly

    Rob/DJ Sizzly Forum Member

    Messages:
    117
    The cue points and stripes are not stored in the ID3 tags. There's no place for 'em. That kinda data is held by the nml database for Traktor. Don't believe me? delete the nml file and then load a track... It'll be virgin.

    But then again, don't do that.... 'cause that'd be bad.

    The purpose of my post was to address the "first play" change to the "modified" date.
     
  7. Rob/DJ Sizzly

    Rob/DJ Sizzly Forum Member

    Messages:
    117
    Oh, and as a side note... Never trust iTunes when it comes to tags... The stuff you see in your database isn't necessarily written to the ID3 tags. Just sayin'.
     
  8. mastermc

    mastermc NI Product Owner

    Messages:
    3,148
    So many people use itunes but i really don't see any advantages other than for playlists.
     
  9. kimhill

    kimhill NI Product Owner

    Messages:
    447
    Actually, there's plenty of space for cue points and stripes in the ID3 tags. See this:

    http://en.wikipedia.org/wiki/ID3#ID3v2

    In fact, Traktor used to store them there in earlier versions. You could delete your .nml file, reload an MP3, and all your cue points/stripes were still there. Not sure how it works with TSP2.

    Actually, iTunes is highly reliable for storing music metadata within the tags. The only gotcha is if you have non-standard/older ID3 tag versions. In that case, it's possible that your metadata may not be written to the file itself. This is unlikely, if you use mainstream encoding software. If there's any doubt, you can just use iTunes to convert the ID3 tags to a current version.

    I think iTunes is the most mature and powerful music manager on the market. Metadata control is very fine-grain, to say nothing of cross-platform integration to iPhone/iPod/iPad...
     
  10. DJ Freshfluke

    DJ Freshfluke Traktor Mod Moderator

    Messages:
    26,779
    nope, that's not true.

    cue points, loops, text tags etc will be stored in the actual mp3 as well as in the collection or playlist file.
     
  11. DJ Freshfluke

    DJ Freshfluke Traktor Mod Moderator

    Messages:
    26,779
    the same.
     
  12. Rob/DJ Sizzly

    Rob/DJ Sizzly Forum Member

    Messages:
    117
    Okay. Then I have a question...

    When my files move from one location to another (due to organization of my music, etc) how come the queue points don't travel along with the file? Is there something I have to do in order to get them to sync with the track?

    And another question: I use Sonar X1 producer and when I import a track I usually have to scrub the track tags before importing or I get an error. Could this be the cause?
     
  13. Count Zero

    Count Zero ModerAUtor Moderator

    Messages:
    6,586
    You could use consistency check to relocate your files after a move and everything should be as it was. If the CUE's etc don't follow the file then for some reason traktor cannot write to the file. (Set as read-only?) Or your music manager is deleting the traktor metadata extensions.
     
  14. Rob/DJ Sizzly

    Rob/DJ Sizzly Forum Member

    Messages:
    117
    I'll try the consistency check.

    How about the Sonar question?
     
  15. Count Zero

    Count Zero ModerAUtor Moderator

    Messages:
    6,586
    Haven't a clue.
     
  16. kimhill

    kimhill NI Product Owner

    Messages:
    447
    Sounds plausible to me. When applications write custom ID3 tags (with application-specific metadata like stripes), there's a possibility that one application's implementation will step on another's. E.g. a few years back, Traktor's ID3 tags would wipe out iTunes' cover art. This was eventually fixed -- not sure whose implementation had the problem...