It would be nice if Picard could read regular audio CDs (at the moment I have to rip them to mp3 with Nero Express), and extract:
a. Track information directly (or via temporarily generated mp3)
b. Fingerprints from the tracks that can be used to assign acoustID tags (currently I have to run the acoustID fingerprinter)
c. ISRC, are on many CDs, but I have been unable to read with any software so far
I also find that I can’t match a CD with newly added information, and have to wait several hours until it appears in the MusicBrainz database; the latter has a “direct search” option which Picard does not seem to use.
As was said on the old forums already, you should preferably not use a lossy format (such as MP3) but a lossless one (such as WAV) when ripping for AcoustID.
It is available in the database immediately, just not in the search index. You can always get it into Picard via the tagger icon.
My mistake, I must have misread it, .wav it is, though ideally, it would be great if Picard could work out the acoustID directly.
I did try adding the releasegroupID directly as a tag to a new cluster, and I still had to wait the several hours before Picard could then identify it.
The ISRC extraction and submission would be possible without full ripping support, even with the existing implementation of libdiscid. I’d love to see this. But as you have experienced yourself ISRC extraction often doesn’t work. It is very dependent on the CD drive used, and various tools apply different strategies to extract ISRCs which might or might not work in your case. Currently I use the isrcsubmit Python script at https://github.com/JonnyJD/musicbrainz-isrcsubmit for ISRC submission.
I don’t think Picard should focus on ripping at this time. I’d rather see it go in the direction of being a complete CD metadata package.
When I put a CD into Picard, I want it to get the DiscID, read the ISRCs and fingerprint all the tracks. I want to then submit all that data to MB in one go. Currently, I have to use 3 programs to do this. Picard for DiscID, then isrcsubmit.py for the ISRCs and a ripper to get the files Picard can read to get fingerprints.
But the only way to get the fingerprints, is the rip the CD. Whether that’s a permanent rip (= it gets stored on drive) or a temporary one (= it gets stored on volatile memory), it still requires copying the audio data off the disc and into the computer’s memory. If you don’t want Picard to focus on ripping, there’s no way for Picard to do fingerprinting directly off the CD.
By ripping, I meant format shifting the contents of the disc to a re-encoded file format stored on another medium. Just reading the track to memory isn’t ripping.
Picard wouldn’t have much work to do in that category, anyways. OS X, Windows and Linux all abstract the audio tracks into common file formats that can be easily read. Just open those for fingerprinting.
I completely agree with you. I think adding real CD ripping support would be overkill, would make the tool more complicated then necessary and even harder to maintain with the existing developers.
It’s just from a technical point of view a lot of the ripping functionality would be required just for the acoustid / fingerprinting support directly from CD, even if Picard would not expose the ripping part to the user. And I fear that makes it currently rather unlikely somebody will implement that functionality, as much as I like the idea behind it But maybe somebody feels motivated to go for it now when reading this discussion
Just to clarify: What I understand when I talk about ripping here is indeed extracting the audio data from the CD in more than real time (playback is not ripping). The conversion into different audio formats afterwards is just that, boring audio format conversion
And to address iantresman: To get the raw audio data to memory you have to read it from the CD. That’s the “ripping” part we’re talking about
Personally, I’d rather that the software did not need to make copies of the CD audio tracks in another format on my PC, I just want it to scan the audio CD into memory (I don’t care which format), and then fingerprint it to acquire the acoustID.
My understanding is that all that is necessary is to just feed the PCM
stream into the fingerprinter, like any other decoder would.
Yes, that’s correct. Picard already supports fingerprinting, so once you have the audio data the rest is trivial. A lot of the discussion misses the point. Feeding audio data to the fingerprinter is trivial, doing audio format conversion isn’t necessary (and even wouldn’t be too hard if it was) and whether the data is stored completely in memory or in a temporary file is just an implementation detail. But you have to extract (trying to avoid the word ripping here as it confuses folks) the audio data from the disc, and that’s the messy part. You basically implement 80% or the functionality of a full CD ripping software for this, and have to do so in a cross platform way.
Not saying it is impossible or anything, just that the relatively high effort and the added complexity in Picard makes it unlikely this will happen soon.
This is not really that simple, as @outsidecontext mentions. https://thomas.apestaart.org/thomas/trac/wiki/DAD/Rip discusses some pitfalls, but there are a lot of things to consider when extracting audio from a CD: hidden track ones, pregaps, scratches, faulty drives, drive read offsets, drive audio caching, CD DRM techniques, …
If Picard is to properly extract audio from a CD to feed to its fingerprinter, it would have to be able to deal with all of the above. Using dedicated ripping software (I like morituri) will likely get you better results than anything we could cram into Picard, without making Picard an actual ripper (and possibly even then).
I think that’s the argument that was originally presented, there was just some confusion in terminology. “CD Reading” aka “extracting audio from a CD” is what a ripper does. Any tool that does that is a ripper – regardless of what it does with audio after it’s been extracted. That’s why the general consensus is that Picard should not become a CD ripper, which is what it would need to be in order to fingerprint CD audio.
Good news is, that the 1.4 branch does support this on OS X. 1.4 supports AIFF/AIFFC, so that means Picard can read CD tracks on OS X as OS X presents CD tracks as AIFF/AIFFC files to the filesystem.
Just don’t try to scan more than one track at a time. Since Picard scans several files simultaneously, you will have a lot of seeking on your disc drive.
But maybe somebody feels motivated to go for it now when reading this discussion