illustrate
Products            Buy            Support Forum            Registrations            About           
 

CD Ripper default to MusicBrainz

Collapse
X
 
  • Time
  • Show
Clear All
new posts

  • Doug Mackie
    replied
    Thank you for this useful reference, Spoon.

    I hope that this naming error is on your fix list. Otherwise users will continue to be baffled when their catalog numbers do not appear as expected in other applications.

    Leave a comment:


  • Spoon
    replied

    Leave a comment:


  • MarkSealey
    replied
    Thanks, Spoon - if this is in reply to mine (and not Ian's), may I ask you to give just a little more detail (where and how), please: still learning. Thanks!


    Originally posted by Spoon
    Use the DSP effect ID Tag Processing set to map the tag

    Leave a comment:


  • Spoon
    replied
    Use the DSP effect ID Tag Processing set to map the tag

    Leave a comment:


  • MarkSealey
    replied
    Doug,

    Thanks so much for your reply!
    Originally posted by Doug Mackie
    AFAIK this name error is hard-coded in dBpoweramp and must be fixed by the developers.
    I use Mp3tag for tag editing and music file management, and it allows mapping of tag names. So what I did was to map the dBpoweramp tag name to the standard tag name, which allows the data to appear in Mp3tag. This was not a fix but a workaround.
    I did not try to create a custom tag name in dBpoweramp called CATALOGNUMBER but you could try that.
    Thanks. What I actually did was add 'CATALOGNUMBER' in dBpoweramp itself as a 'new' item; when saved and imported into my tagger, Yate, that field was there as well.

    Solved! Thanks. Your knowledge of the standard did it. Much appreciated :-)
    As for your screen shot, sorry but it is too small for me to read the text.
    So sorry :-( I'm partially-sighted myself so I do sympathize.

    On a Mac you can drag any image from the browser (at least Safari and FireFox) to the desktop to look at them in graphics software.

    I think I'm almost set now.

    Although more thorough documentation on this aspect of dBpoweramp > CD Ripper would be helpful.

    Thanks again!

    Leave a comment:


  • garym
    replied
    Originally posted by Ian Berrington
    Hi guys, I've been busy. Ripped the entire collection into FLAC as well as MP3. After that using another program a bit iffy I managed to rip to ISO about 200 out of 220 DVD's. Took some time and the other program was about all I could find for DVD'S, they are all Chinese and a bit dodgy.

    I'm now going back to some audio discs I had issues with before. I'm ripping to files on a MacBook (not iTunes) with ultra secure enabled. I have quite a few black CD'S and am using an Apple USB Superdrive to rip. Almost all of the black discs are giving me problems from insecure rip to getting stuck in the drive or sometimes just ejecting on their own. Is there anything I can try in settings to improve the results? Thanks in advance.
    you should probably start a new thread. this is buried in the MusicBrainz tagging thread but has nothing to do with this so likely won't be seen by many. To answer your question, I'm not aware of any setting that would help. But others may have ideas.

    Leave a comment:


  • Doug Mackie
    replied
    Originally posted by MarkSealey
    If so, may I ask, please: how would I correct this in dBpoweramp - given my settings as per the grab in my post above?
    AFAIK this name error is hard-coded in dBpoweramp and must be fixed by the developers.

    I use Mp3tag for tag editing and music file management, and it allows mapping of tag names. So what I did was to map the dBpoweramp tag name to the standard tag name, which allows the data to appear in Mp3tag. This was not a fix but a workaround.

    I did not try to create a custom tag name in dBpoweramp called CATALOGNUMBER but you could try that.

    As for your screen shot, sorry but it is too small for me to read the text. The forum software may be to blame.
    Attached Files

    Leave a comment:


  • Ian Berrington
    replied
    Hi guys, I've been busy. Ripped the entire collection into FLAC as well as MP3. After that using another program a bit iffy I managed to rip to ISO about 200 out of 220 DVD's. Took some time and the other program was about all I could find for DVD'S, they are all Chinese and a bit dodgy.

    I'm now going back to some audio discs I had issues with before. I'm ripping to files on a MacBook (not iTunes) with ultra secure enabled. I have quite a few black CD'S and am using an Apple USB Superdrive to rip. Almost all of the black discs are giving me problems from insecure rip to getting stuck in the drive or sometimes just ejecting on their own. Is there anything I can try in settings to improve the results? Thanks in advance.

    Leave a comment:


  • MarkSealey
    replied
    Doug,

    Thanks so much for that!

    I have to say, it looks promising, doesn't it :-)

    Originally posted by Doug Mackie
    …turned out to be simple: catalog numbers were indeed stored in the ripped files but with a nonstandard tag name: CATALOG #.
    … … …
    FLAC: CATALOGNUMBER
    That would certainly explain it, wouldn't it! (I use only FLAC)

    If so, may I ask, please: how would I correct this in dBpoweramp - given my settings as per the grab in my post above?

    …In other respects, the ripper works great for me…
    Same here. I recently extended my subscription to well over 700 days :-)

    Thanks again - your help very much appreciated!

    Leave a comment:


  • MarkSealey
    replied
    PeterP,

    Thanks for jumping in here! I love dBpoweramp; but want to make sure I have every last configuration set as optimal for ripping my CD collection :-)

    Originally posted by PeterP
    Please check CD Ripper Options / Meta Data & ID Tag / ID Tags / Write ID Tags
    Make sure Catalog # isn't unchecked on the list of tags to write.
    Yes; have checked - and it's as it always has been: checked.

    This screen grab shows an example. Say that I want to rip this CD:

    Click image for larger version

Name:	Catalog number not saved.png
Views:	296
Size:	200.6 KB
ID:	327977

    I think those settings in CD Ripper are correct, aren't they?

    Also, what other program isn't reading the Catalog # tags?
    When I load the ripped files in their folder (named 'CD1' etc) into Yate, there is no Catalog number in that field there.

    Are these tags visible in dBpoweramp itself, if you navigate Batch Converter to ripping output folder, right click some file and Edit ID Tags?
    Yes.

    Thanks for any pointers that you can give, please, Peter!

    Leave a comment:


  • Doug Mackie
    replied
    Originally posted by PeterP
    Please check CD Ripper Options / Meta Data & ID Tag / ID Tags / Write ID Tags
    Make sure Catalog # isn't unchecked on the list of tags to write.

    Also, what other program isn't reading the Catalog # tags?
    Are these tags visible in dBpoweramp itself, if you navigate Batch Converter to ripping output folder, right click some file and Edit ID Tags?
    In my DBPA rips I could never read catalog number tags in other applications. Output files from the Music Converter had the same problem. All other tag values set by dBpoweramp appear as expected in all my applications. The reason turned out to be simple: catalog numbers were indeed stored in the ripped files but with a nonstandard tag name: CATALOG #.

    The standard tag names are:
    MP3 TXXX:CATALOGNUMBER
    MP4: com.apple.iTunes:CATALOGNUMBER
    FLAC: CATALOGNUMBER

    These names appear in the tag mapping tables at Hydrogen Audio. "CATALOG #" is not listed there for any file type.
    I have not checked all types of dBpoweramp output files for this naming error, but that might be a good idea. In other respects, the ripper works great for me.
    Last edited by Doug Mackie; September 19, 2024, 04:13 PM.

    Leave a comment:


  • PeterP
    replied
    Please check CD Ripper Options / Meta Data & ID Tag / ID Tags / Write ID Tags
    Make sure Catalog # isn't unchecked on the list of tags to write.

    Also, what other program isn't reading the Catalog # tags?
    Are these tags visible in dBpoweramp itself, if you navigate Batch Converter to ripping output folder, right click some file and Edit ID Tags?

    Leave a comment:


  • MarkSealey
    replied
    Spoon,
    Originally posted by Spoon
    Does not stick as in, if you click off the track and back to it, it is gone?
    No.

    or when ripping, there is no catalogue number?
    Yes; that's right: although I can enter each catalog number (which I get from various sites with each CD's details) before ripping (and it always does stay in the vertical 'Meta' tab), it's never there - for any of a good three or four dozen labels whatsoever - when I then load it into my tagging software.

    PerfectMeta takes data from all the databases and cross checks for errors.
    That seems like the best of all worlds. So (how?) can I force a rip to take (only, first) from PerfectMeta, please?

    Leave a comment:


  • Spoon
    replied
    Does not stick as in, if you click off the track and back to it, it is gone? or when ripping, there is no catalogue number?

    PerfectMeta takes data from all the databases and cross checks for errors.

    Leave a comment:


  • MarkSealey
    replied
    Thank you, Spoon!

    I've been doing this for months (years?!); never sure what I'm doing, though.

    I suspect(ed) I could tweak it a bit.

    When you say that the 'system [can] work it out', do you mean I just let CD Ripper somehow grab all those database's data; and that it will then fill in each field with what dBpoweramp 'knows' to be the most accurate?

    How does it do that?

    I'd also like to put catalog numbers in. But I can't get them to stick - even when entering manually in the Meta vertical tab.

    Any ideas, please?

    Thanks so much in advance… !

    Originally posted by Spoon
    You would enable them all and let the system work it out. For classical there is no better database, they are all so-so with regards to classical (such as composer, conductor).

    Leave a comment:

Working...