How would Picard be able to submit any ISRCs without actually obtaining them first by either reading and decoding the Q channel of a CD, or parsing some trusted 3rd party source such as EAC CUE file?
If Picard can calculate the disc ID by reading the CD, then why can’t Picard get the ISRCs off the CD?
1 Like
I guess there’s rather a big technical difference if you only need to read the TOC (table of contents) or decode a specific subchannel. And some drives can’t read the latter at all.
1 Like
Agreed, my point was that while a user is submitting a disc ID, it makes sense to submit ISRCs as part of a single set of actions. Obviously, they may not be available, so could be skipped.
1 Like
@dpr - The topic appears now and then. Linked above is a good response for you from one in the know. 
Buggy CD players can give out duff data and it is on the TODO list. (Warning, that whole thread is lots of long chat in circles… you only need to look at that one post linked and the one before it)
Thanks for the link to the discussion. As an advocate of ISRCs I had already read it, but read it again…
I thought about Picard and it accessing CDs on and off over the day. My conclusion is that It doesn’t make sense to me. I understand Picard to be the software I use to tag files that have already been encoded from a CD or downloaded. tI doesn’t have any ability to rip CDs, so adding any functionality to read from CDs - the TOC and/or ISRCs etc seems misplaced. Those things be part of software to help add releases to Musicbrainz - including their disc IDs, tracks, track lengths and any ISRCs that are on the CD.
The flow seems to be:
- Determine if the CD in my hand is already described on MB
- if so, use it’s description and add to the description if needed
OR - if not, added it - with TOC and ISRCs etc
- Get the encoded files:
- Rip the CD and encode it with the information from MB using EAC or cuetools etc)
OR - Purchase and download
- Extra tagging of the encoded files with Picard
Many tools have already solved the problem of reading from CDs well. Does Picard need to copy this?
I don’t think so. In an ideal world the ripper would include MBIDs found when it looks up the CD.
Reading a TOC makes sense for Picard to upload a DiscID which then allows for much better matching of Release versions. As someone who rips with EAC I like that addition of uploading the EAC logs as I often go back to them as they are sitting with my FLACs.
Personally I combine EAC and Picard when ripping and uploading a new album.
- Picard - read the new CD, submit the DiscID.
- MusicBrainz - add a track list (clone a release\copy paste). Push data back to Picard.
- Next to EAC and it is ready to rip as it will find the CD with the built in MusicBrainz lookup. I let EAC basic tag as it will set the file names.
- Then back to Picard and set the tags in detail. (Picard does not touch my filenames)
- Picard will download the art.
- Finally I upload AcoustID data.
While the rip is going on, the scanner is chugging, and I am filling in all the other data from the book. Usually I have to return to insert the artwork as that usually takes longer to do than the ripping.
If ISRC could easily fit in there, I’d submit it. But I see no use for it at all in my process of identification. Especially as I don’t trust the errors, and many of my CDs are too old for it anyway.
1 Like
That’s your use.
But I use Picard primarily to submit data to MB.
I also usually don’t rip my files, except if I really want to submit AcoustID and when I am on Windows, because on my Linux, I can directly submit them with Picard from CD virtual files, without ripping saving files.
When I rip (on Windows), it’s foobar2000 which will tag my CD tracks before ripping temporary files (without titles, it’s difficult to match tracks in Picard for AcoustID submission).
Picard is used either for submitting data to MB or for tagging files, or both.
It makes sense to complete what we can submit from our CD.
With a proper scanning, there are no duplicate ISRC errors.
A perfect ISRC scanner needs two features:
- Search ISRC in CD-TEXT
- Search ISRC in sub-channels by Read[ing] upto 10 Seconds of each track to find 2 Successive Identical ISRCs
Sometimes you can have 2 sets (ultra rare), let the user choose if they are different.
Can you create a release from Picard?
What data do you submit?
Do you mean you don’t rip your CDs? or you have virtual images?
Our steps look quite similar.
EAC extracts the ISRCs for tracks that have them for me and puts them in the cue file it creates.
I though AcoustID was dead on MB?
Absolutely, I press Lookup CD to add a new release from my disc ID.
And sometimes I submit AcoustID with Picard as well.
I listen to my CD with my CD player, not with my computer(s) or phone or walkman.
So I don’t rip them, no.
I don’t have virtual images, I don’t (need to) save them in any ways.
you cant create a completely new relesse and release group for a cd that is not in MB though
Do you know that your CDs degrade / rot overtime?
There are also advantages of portability and protection against damage
Well, hmm? Yes, it’s what I often do.
Instead of finding and selecting an existing release, if none, I press Add new release button.
Go to plugins under options and select “add cluster as release” and you can actually create new releases that way.
1 Like
Where do you type the text for the tags? You can type them in EAC, then tag in EAC. Once those files are loaded into Picard. Cluster then
That will upload tagged data. Or Plugins\ Copy cluster to clipboard option you can paste that tagged data into a MB Release using < Text Parser >
And yes, that also allows creating a new Release and Release Group.
So does adding a New DiscID as I mentioned in my own personal method above.
I prefer that as I can type into the MusicBrainz tracklist page, and then push back to Picard with TAGGER button and hit EAC at the same time.
Multiple routes from Picard to creating a new Release in MusicBrainz
I don’t create CUE files. This could be why I don’t see them. I only create the rip logs for my separated FLAC files. Still a PITA to upload. I’ve tried faffing with it before, and it took too long to be honest with you. I’d rather spend that time on adding the Works.
Nope. Very alive and well. And really useful. It is run by a third party, outside of MB. Great for ID’ing recordings.
Don’t be confused with AcousticBrainz which was something very different.
3 Likes
Just two additions: If tags need changes one can of course also type the tags inside Picard. And instead of the “Plugins > Add Cluster As Release…” you can also use the built-in “Submit cluster as release…”, which is recommended as it solves some issues the plugin has.
4 Likes
This is what I meant about Picard being a many angled tool.
The “type in EAC” is meaning when one is ripping the first time. Then those tagged files come to Picard next for uplooad to the database.
So many different ways of making it fit a workflow. Personally I prefer typing a new release in the larger screen of MusicBrainz as I can copy\paste text into the Track Parser. Then I push that back to Picard and EAC.
Doh! Blind and didn’t see it. Now see it in my own screenshot. Will remove the plugin to re-train my old habits. (Have ninja-edited my above post)
2 Likes
As @tigerman325 has pointed out, I need to add a plug-in. My Picard screen doesn’t have it as I’ve not added that plug-in!
To add a release, I’ve been following the MusicBrainz instructions. Add Release which don’t mention the ability to do it via Picard and a plug-in!
Neither does the quick start guide for Picard or the recommended workflow for when a CD is available.
I keep the ripped iso.
At one point I was using a modified version of a python script called cueproc that parsed the cue file that EAC had created and read the ISRC value for each track and included it (as well as some other tags) in the command line to encode the track to flac or mp3 which the ISRC values included.