Skip to main content
E
emmrecs
Brainiac
February 22, 2018
Answered

Attempting to edit ID3 data, Recording Date seems to return!

  • February 22, 2018
  • 4 replies
  • 2838 views

I guess what I am using AA CC (latest version, 11.0.2.2) for currently is somewhat unusual but ...

I am compiling CDs for a public examination board, the contents of which will be used to train and standardise the work of assessors whose job it is to ensure that all the candidates' work has been correctly marked by their schools, is to the required standards and has been fairly assessed.

The sources of the various musical performances are in a variety of formats, mostly m4a and mp3.  Some of these include metadata which can reveal details of the candidate and school, which should not be included on the final CD.  I use the Metadata panel to remove this ID3 data, including the original recording date, by highlighting any field with data and deleting it.  This is successful for every field except for Recording Date; the initial pressing of "delete" clears the field but moving the highlight to a different field seems to cause the Recording Date field to be re-populated!  It can take three or more repeated attempts to finally convince AA that I really do NOT want the original Recording Date to be retained.

Anybody else seeing this and can suggest a reason?  And a method of removing it without the necessity to "highlight and delete" several times?

TIA

Jeff

    Correct answer SteveG_AudioMasters_

    Took me a little while to get this to happen, as it only appears to re-populate when you click on the date field again - but then it does indeed pop back! I suspect it's a minor bug, and more than likely it's to do with the way the data is buffered. What's slightly more worrying is that any date you put into the ID3 data also makes it into the XMP, from where you can't delete it. Also it populates the RIFF data the same way. I suspect that this might be why it appears to take several goes to eliminate it.

    If you are worried about it reappearing when it shouldn't later, the thing to do is just to put a safe value null string in there (like 0000), because it's whatever the last entry was that reappears. And yes, it appears that you should be worried about it - I tried a save with all the fields clear and it popped back the instant I saved it. So the only 'safe' solution for the time being is to put a null string in, and then it won't matter. I'll report it as a bug, with reference to this thread.

    4 replies

    Borgo81
    Borgo81
    New Participant
    March 28, 2022

    Go to RIFF and change the date. Put only the year "2022"
    Save the files and check, ID3 will change as well.
    Cheers

      V
      vkoivula
      New Participant
      August 27, 2018

      Yes this is absolutely unacceptable to have this type of bug and it isn't even fixed by now. This is a major problem, when I would need to have a proper date in this field for podcast I am editing!

        SteveG_AudioMasters_
        SteveG_AudioMasters_
        Community Expert
        January 6, 2021

        Okay, and update of a sort. I have to tell you that as it stands, it's intended behaviour, and not a bug. It's not necessarily desirable as it stands - obviously - although how it will be resolved is not yet clear. Firstly, it's worth reading the other thread about this (that admittedly I'd forgotten about until Audition's product manager reminded me of it), and that's here. If you want to sum up the gist of it, it's about origination times and a record of events. In summary, it's been suggested that "...this field is captured from xmp.CreateDate which is the date the (original) document was created.  Like similar timestamps in photo metadata, it reflects the day and time of the capture of the original source, and derivatives should have some record of that history.  However, it may not be the right field to populate Recording Date."

         

        The bug report that was set up is still under review, and there are, apparently, differences of opinion about resolving it. The good news is that I've potentially prompted a review, which should resolve this once and for all. Bearing in mind the foregoing, if you want to put forward reasoned arguments as to what you want from the associated metadata fields, put them in this thread. I cannot guarantee what might happen as a consequence, obviously, but this can be fed in.

        Ted Abundant
        Ted Abundant
        Participating Frequently
        January 6, 2021

        I would like recording date to be the current date and able to be edited. 

        If it is based on the original file, I would like it removed.
        It should be an editable option of when the recording date is or when it will be released. 
        If you want to replace it, replace it with "release date". 
        This is used for podcasting and should reflect a more current date for releases.
          dand2063610
          dand2063610
          New Participant
          April 18, 2018

          Any movement on this one?  This is kind of a major issue for our podcasting clients. I'm able to save the null string but this is very frustrating.

            SteveG_AudioMasters_
            SteveG_AudioMasters_Correct answer
            Community Expert
            February 22, 2018

            Took me a little while to get this to happen, as it only appears to re-populate when you click on the date field again - but then it does indeed pop back! I suspect it's a minor bug, and more than likely it's to do with the way the data is buffered. What's slightly more worrying is that any date you put into the ID3 data also makes it into the XMP, from where you can't delete it. Also it populates the RIFF data the same way. I suspect that this might be why it appears to take several goes to eliminate it.

            If you are worried about it reappearing when it shouldn't later, the thing to do is just to put a safe value null string in there (like 0000), because it's whatever the last entry was that reappears. And yes, it appears that you should be worried about it - I tried a save with all the fields clear and it popped back the instant I saved it. So the only 'safe' solution for the time being is to put a null string in, and then it won't matter. I'll report it as a bug, with reference to this thread.

            E
            emmrecsAuthor
            Brainiac
            February 22, 2018

            Thanks for the investigation Steve, and for the confirmation that it's not caused by some silly action (or inaction) on my part.

            Thanks also for the workaround!

            Jeff

            SteveG_AudioMasters_
            SteveG_AudioMasters_
            Community Expert
            February 22, 2018

            It's now reported as a bug, referenced to this thread.

              Terms & ConditionsAccessibility statement
              Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices