Talk:Beginners Guide

From MusicBrainz Wiki
Jump to navigationJump to search

Beginners' Guide > Beginners' Guide Discussion

Beginners' Guide Discussion

I am a newbie to Picard. I loaded up Ubuntu 10.04 and just downloaded the package. I have a large music collection, some CD, some transferred vinyl. I would really like to use Picard to clean up and extend the metadata in my music collection, hopefully in an automated fashion. I don't think I have enough time left to live to do the task manually. I realize that automated metadata updates on vinyl transfers are dicey at best.

I have some background with iTunes and other music database systems. So I approach Picard by trying to fit it into my knowledge of other packages, but it doesn't fit. So lets start at the 30K foot level.

What is Picard? It seems any intro would want to start with a statement of this sort. Something along the lines of intended purpose, expected users, expected usage, and most importantly, what Picard is not. Picard appears to allow one to update the metadata of one's MP3 audio library. Cool, what format? There are about three of them last I looked. What does Picard use? Can you specify which one to use? Can you convert? Does Picard just overwrite whatever metadata it finds, or can you have a finer control of the process? Can you get it to ask you before making changes? If it decides my Mama's & Papa's "California Dreaming" is really Jimi Hendrix playing "Vodoo Child", can I correct it? Is there any kind of summary screen to show me what changes it made?

I dragged and dropped my music collection into Picard. The menu system didn't seem to work for me. In iTunes, this would create a large, permanent database of artists, albums, and titles in my documents directory. What does Picard do with my tunes? It doesn't seem to power up with my library loaded like iTunes does. Must I drag & drop my collection into Picard each time I invoke it? Does this imply it needs to live loaded and minimized in the toolbar? Why is there no corresponding "load" to complement the "save" option in the menu system? Am I expecting too much? Is this just a one-shot metadata lookup that expects another music manager to play the music?

A scan on my music collection took 2 days to complete, so proper usage is a non-trivial issue with me. I can't throw that much CPU time away on a whim. I really can't afford to screw this up!

If I select save, what gets saved? All the music data looked up? Is it saved back to the original files or are they backed up? How come no artwork gets loaded?

Terminology: OK, what is a cluster, and how does it differ from an album? How does one convert one to the other? Is it better to have clusters or albums? What are the tradeoffs? Why are there two? Why not just one?

In what way does a "cluster" lookup differ from a "scan"? Do scans update clusters? Does a cluster scan update albums?

How about a couple of typical usage scenarios with commands and expected results? Say one for cluster search and one for scan maybe....

This shouldn't be such a mysterious tool. I don't want to play "adventure" with my software tools. Just tell me what to expect, and that shouldn't take 300 pages to do.

A pox upon the doc writers.

Greg capngp@hotmail.com



Low-distribution releases

I question the inclusion of the sentence "Thus your local factory made various artist disc may not be accepted for its very slim range of user need." - is this really true? It seems to discourage releases from being added, when the intent, if I interpret it correctly, is really to discourage homebrews from being added. -- BrianSchweitzer 02:47, 23 May 2007 (UTC) DeleteWhenCooked

  • It is EXACTLY true: it MAY not be accepted because you won't be able to bring proof of its existence. Although, if you show a scan of the cover, I think such a release will be accepted. --davitof 2007-05-25 DeleteWhenCooked
    • I think you missed my point. Hell, I' one of the ones leaving hundreds of "proof please" notes on the add edits every week. I'm saying that the phraseology we're using seems to discourage adding low-distribution releases. We find proof/verification for releases with printed copies in the low hundreds in some shape or form every day. It's not a big issue. The wording, "may not be accepted for its very slim range of user need," is what concerns me. It implies that we are making a value judgement on the "worthyness" of a release to be in the database, when what we're really trying to say would, I think, be better said something like, "Thus, though it may be difficult to find a link which may be used to verify your release, especially for small-run releases, we appreciate your doing all you can to find some way for others to verify your release. If nothing else, a link to a scan of the liner is always happily accepted." We already cover "homebrew = bad" earlier in the page; here we more ought to be addressing the value of verification for releases in a way that doesn't discourage the diversification of the database. -- BrianSchweitzer 04:27, 16 June 2007 (UTC)
      • You were right, I missed your point. And I agree with you. --davitof 2007-06-17

Tracklisting issued twice

The term Release covers full-length albums, singles, vinyls, cassettes, etc (see ReleaseFormat). A release is made of one or more Tracks. If a CD with the same tracklisting is issued twice, once as a stand-alone release, once in a set, it may have to be entered into the database twice (see Release, BoxSet and BoxSetNameStyle).