So, first off the webjay ‘em all button was broken. This was because the URL given for each page was missing the http:// preamble to the domain name. I fixed that over on Webjay and am now listening to http://webjay.org/by/playth... and it’s really pretty cool, in the sense that it’s informative to hear all the remixes together.

However, the next bug is that Webjay can’t auto-fetch metadata, at least not yet, so the net result is lacking the license info, song title, and artist name. The playlist sounds fine, but it’s dog ugly.

To see what it looks like, hit the webjay button.

The best way to approach this, I don’t know. What I want to do here is just to start a conversation about it and see if there is a simple solution.

Quote: So, first off the webjay ‘em all button was broken. This was because the URL given for each page was missing the http:// preamble to the domain name. I fixed that over on Webjay
Well, this is a bug on our side, if you doing a check for http:/ then I’ll just fix it here, otherwise let me know when it’s good for you and I’ll make the fix here.

Quote: However, the next bug is that Webjay can’t auto-fetch metadata, at least not yet, so the net result is lacking the license info, song title, and artist name. The playlist sounds fine, but it’s dog ugly.

You should absolutely be seeing the license (in TCOP) we’re definitely stamping into every song on upload and our CC Verify tool sees it for sure.

I think it’s fair to do the following: if there are no title or artist tags in the MP3 then we just stamp them in with the CC Mixter artist name and song title the user typed into the form. (I just checked in that code but I didn’t run over all the current uploads so you won’t see that until we get some more submissions.) If either tag exists then we respect whichever is there and leave it alone.

Sound good?

Victor

Quote:
Well, this is a bug on our side, if you doing a check for http:/ then I’ll just fix it here, otherwise let me know when it’s good for you and I’ll make the fix here.

I think it’s a good thing to fix it on mixter too, but the parser on webjay’s side is intended to be DWIM, so it’s fine to handle it there.

Quote:
You should absolutely be seeing the license (in TCOP) we’re definitely stamping into every song on upload and our CC Verify tool sees it for sure.

I don’t touch the MP3s, though — too much bandwidth, potential legal problems, complexity of code, code being limited to MP3. I think the best solution is for me to parse the embedded RDF for metadata, so I have posted a couple related items in this forum.

How does that strike you, Victor? If you’re in agreement with that solution, we might want to consider this bug closed out and think of the others as replacing this one.

ah, I mistundertood, ok, I get it now…

The CC metadata is only on the song page which is ‘by design’ it’s really the only place it ‘needs’ to be for the verifyer to work.

If you can parse the /file url along with the /contrib url then you’re there. Does that make sense?

The other posiblity is to have a /verify/username/filename url that I could cook up that only returns the xml.

Victor

Quote: If you can parse the /file url along with the /contrib url then you’re there. Does that make sense?

The other posiblity is to have a /verify/username/filename url that I could cook up that only returns the xml.


Hm. Good questions.

It seems to me that I *could* go to the /file URL or to a /verify URL and fetch the metadata from there, but it would be a ccmixter-only solution. The generic way to do it is to look for CC RDF in the current page and stop there.

Alternatively, there could be a link rel="license" that pointed to the RDF.

These are both fine solutions from my perspective. …

ok, the webjay link is emitting http.

wrt to metadata of course it’s possible to emit meta data for each mp3 pointed to (do people do that?) It’s not a big deal to get that to work if you really think that’s what’s needed. But sure would be overkill on a page like http://ccmixter.org/tags/remix wouldn’t it? Seems like a slippery slope.

I’m a little hesitant because frankly, I don’t know what the rules or ettique is about these things (or a whole lot of *other* things either but that’s a subject for another day…)

Victor

I am only slightly less unable to follow etiquette when I know it than I am to figure it out in the first place. Given that, as far as I can figure out there should always be CC RDF in a page with links to MP3s.

And speaking of the tags pages, that’s an ideal place for a webjay em all button. EG listen to all remixes:
http://webjay.org/playthisp...

Listen to all things with scratching:
http://webjay.org/playthisp...

…etc.

looks like I answered you but I was spell checking while you posted…

I don’t want you to have a ccmixter-only hack, I appreciate it but it shouldn’t be necessary.

I thought about the <link solution, would that actually work for the multiple file case? If so it will take me a second to jam into the right templates and make sure I have the right formatting

VS

The link solution would work great, Victor. Thanks for doing it!

ok, first the dishes in the sink, then we’ll see about link.

Regarding the /tags pages there’s RSS coming for all those, I’m assuming a <link tag pointing to the rss will suffice?

VS

Um, well that’s different stuff I think, because it’s RSS instead of RDF, and RSS contains metadata about journal entries rather than about songs. I was link of a new rel="license" value for the link element.

It seems to me there are two solutions, one I mentioned in http://ccmixter.org/forum/v... (embeded RDF for each mp3 linked to)

the equivalent solution would be to link to RDF generated specifically for the page, which would contain the same statements as would the embedded RDF above.

Ok, so what I’m going to do is look for an RSS autodiscovery link and, if I find it, use that as the source to scrape.

Thx.

wrt to rss: the flavor I was thinking of using is RDF, see http://del.icio.us/rss/math... for how it might look, plus I would add some cc:license xmlns. Seems like it could also serve scrapers (albiet with an extra GET). fwiw this will happen for feeds either way.

Having said that I’m not against embedding some of the meta data into the html as well. OK, so I’m a little against it. I *do* think doing it every place we emit an href to an mp3 is overkill (*cough* http://creativecommons.org/...

/, /tags/{tag}, /by/{artist} ok but probably not search results.

mike: I didn’t follow your post about what the actual embedding should look like, (maybe some tags were stripped by the forum) email me a snippet offline so I can get a better look.

Victor

OK, rdf style rss should be working throughout (most) of the site.

I don’t think you have to be logged into Bloglines to see this (a feed watching uploads of samples)

http://www.bloglines.com/pr...

Let me know If that format looks OK… I was kind of winging it.

I’m definitely warming up to embedded rdf as well so let me know what the format should look like.

Victor