title
Products            Buy            Support Forum            Professional            About            Codec Central
 

CD Ripper: Custom & Fixed Value Tags

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • mville
    dBpoweramp Guru
    • Dec 2008
    • 4015

    CD Ripper: Custom & Fixed Value Tags

    I would like to see a tweak to the R14.3beta CD Ripper Custom & Fixed Value Tags option.

    Currently, when a CD is inserted, the Tag appears with the fixed value in the Meta Data section.

    However, I would like to see this tag (and value) written to (and read from) the dBpoweramp local cache.

    So, on insertion of a CD, if the CD exists is in the dBpoweramp local cache and the custom tag exists in the cache, display this tag and value, if not, use the Custom & Fixed Value Tag setup in the CD Ripper options.

    Hope this makes sense.
  • mville
    dBpoweramp Guru
    • Dec 2008
    • 4015

    #2
    Re: CD Ripper: Custom & Fixed Value Tags

    Found a similar thread to the above post:

    Spoon... We create custom tags for such things as Producer, UPC, Label, Location and Copyright when ripping CDs using R13.5 or now R14. Note: We create the custom tag UPC even though it is also checked in the Write ID Tags list. Otherwise, this field name does not show up in the Meta Data for All Tracks display at the bottom


    Is this issue a bug? If so, will it be fixed?

    Comment

    • Spoon
      Administrator
      • Apr 2002
      • 43915

      #3
      Re: CD Ripper: Custom & Fixed Value Tags

      We fixed that bug in R14.1
      Spoon
      www.dbpoweramp.com

      Comment

      • mville
        dBpoweramp Guru
        • Dec 2008
        • 4015

        #4
        Re: CD Ripper: Custom & Fixed Value Tags

        Originally posted by Spoon
        We fixed that bug in R14.1
        Well, the bug is back in R14.3 beta.

        Comment

        • ClassYK
          • Apr 2012
          • 11

          #5
          Re: CD Ripper: Custom & Fixed Value Tags

          Well, I experience the same bug in R14.2 Registered Reference.

          Comment

          Working...

          ]]>