How do I handle buttons (i.e. graphics) with text on them?
You can use the background= feature of cells to place a background 'button' graphic in each table cell. As long as the cell is bigger than the graphic, the 'button' will float to the top left corner. Then use align (likely top and left) to get the text in the right spot. Be sure and use contrasting colors properly. Make the text part of an link, and away you go.
Fit and finish -- use CSS to suppress the decorations on the text, since it already looks like a button. Don't forget the ALT tags! Conveniently, you will also be text-enabling your pages.
All this applies whether you use a EN#FR#DE style inline in the page, or an exernal approach. The external approach works better if the text is unlikely to change often - things like a database access site, for example.
Re:Faster brains not faster machines
on
Faster
·
· Score: 1
"Civilization advances by extending the number of important operations which we can perform without thinking about them."
--Alfred North Whitehead, An Introduction to Mathematics
The artist gets paid the same way Slashdot gets paid - via that banner at the top of the page you just saw.
You count the click-throughs, but - just as with letters to the editor - every click-through represents so many thousand viewings of the banner. The sponsor is paying for the clicks, at some pre-determined CPM rate, knowing that everytime they pay 2.5 cents for a click, another 1000 or so also saw their sponsorship banner.
This isn't a lot different than bigmultinational!.com sponsoring the artist's tour in order to share in the attention that tour generates.
Of course, smart sponsors will put something really interesting and worth coming back to at the end of that link, not just another hi-I'm-a-sponsor page.
"Artists should get paid for their work." -- Aimee Mann
This, I think, is the core of the matter. It's also interesting that this is not, by and large, what the labels are saying. They're talking mainly about "artists' rights", while the artists figure they worked hard, and really ought to get paid, thank you.
So, I'll lay out the idea below again. I've run it through various discussion forums at mp3.com a couple of times, and nobody really noticed. I thought it was simple and straight-forward, but maybe it really is revolutionary...
First - you can't digitally protect music. If you encrypt it, then you have to decrypt it to use it, and unless you're using secure hardware, that protection won't last long. [see deCSS] You also can't use watermarks for that reason - if someone can identify the watermark, then they can remove it. You can identify music using watermarks, but only to determine that piracy and illegal distribution has taken place. You can't actually distribute the watermark check (see above). And if all else fails, someone will just digitize an analog copy.
It's beginning to look like it's digitally hopeless to try and protect music, until you realize that's not the goal. You just want to pay the piper. Literally.
Everyone's worrying about music distribution, but as MyMp3 and Napster show, the distribution problem is solved. We're just waiting on a little more bandwidth and disk space, and it will be solved for everybody forever. The distribution cost will be so low, that you would pay more to control the distribution than you would to actually distribute the content.
So, rather than worry about a solved problem, how can we pay the musician? The other time-honoured method of paying for music is pay-for-performance. This could be like a penny-an-hour radio station, but this ignores portable MP3 players and large hard drives. Last time I checked, I can't connect anywhere while I'm riding the subway.
The next step in the thought process is to let you store the music, but whenever possible, the player notifies... well, it notifies someone of this selection. Ah, yeah, right. I don't want to think at all about the privacy aspects of that model. [see RealAudio]
The final ah-ha is realizing that I don't need to charge for all performances, or even most performances. I just need a good-enough sample of how often the music is selected. This, it turns out is easy.
First, you embed additional information in MP3 files - you can do this today without breaking existing MP3 players. [see MP3,ID3v2] We can squeeze in about 64K for the equivalent of about 4 seconds of audio - in other words, it's really inexpensive. In this 64K, you get about 3 or 4 sets of information. Each set is for one entity - the artist, the label, and (critically) one or more for sponsors. Each set has (a) a big banner advert, (b) a tiny banner advert, (c) a 16x32 black and white logo, (d) a name (ascii), and (e) a special URL.
Now, crank up that compiler, and go back to your open source MP3 player. When you encounter this block of data, display the appropriate chunk from the section. Try for the big banner, or just use the small one. Portable players with a graphic screen can go for the 16x32, and the really simple portable players will go with scrolling the name. Then cycle through each set, moving forward about once every 20 seconds. Finally - if someone selects the banner, logo, or name (by clicking - or whatever) then launch that special URL. Notice that the selection is clearly a user action - nothing happens unless the listener does something.
The URL is very special. It uniquely identifies the advert, and also uniquely identifies the tune. It could uniquely identify the original download as well, but that's up to the distributor. Before launch, the player will add the X and Y address of the click on a banner, and a hash code (with salt) of the following few seconds of music.
The server that receives the URL will redirect the user to something appropriate - artist, label, or sponsor - to what was clicked. If it is a sponsor, it records the click-through. But as it does the redirect, it notes the tune that it came from. That's all for the core technical stuff. The server itself would sensibly be the label's, but there's no concrete requirement for that.
Now look at the information stream you're getting. The number of click-throughs is going to depend on both how widely the file is distributed and how often it is listened to. These are the core attributes we want to measure for music popularity. In addition, since sponsors get a click-through, the artist and label can share a click-through revenue stream and an impression stream. As a final note, if you let the URL identify the specific download, then you can get loyalty points for downloading and distributing tunes to your friends.
So, did we achieve what we were after? I think so (but then, I'm biased). We have:
a benefit from hyper-distribution (or "Napster is our friend")
measures of performance, not just distribution
revenue sources for the artists and labels
Conveniently, this is completely compatible with streaming MP3, so netradio works immediately and automatically generates the artists revenue stream. I don't think there will be a lot of pressure from artists and labels to penalize (or even regulate) netradio if it is going to automatically generate income.
Yes, you could strip out the information and pass on the file. But this has relatively little effect. With legitimate hyper-distribution it becomes very difficult for a pirate to get their works out to a lot of people.
Most conveniently, this is completely backward compatible with MP3. Artists could start adding sponsor info to downloaded MP3 tomorrow, and it won't affect properly built players. Once a large enough base of tunes exists, players can be reasonably expected to support the option. As a final nice touch, this can even move into the physical world, by including pre-encoded MP3s on the end of each CD, ready to move to the PC, stereo, or portable player.
So - final question. Would this model help solve some of the difficulties we're having here?
Then you should be able to bypass a number of blocked URLs using the following workaround.
1) get the URL you are interested in 2) look at the tail of the URL 3a) if it already has parameters (there is a "&" in there somewhere) sneak in your own random parameter by replacing a single "&" with "&random=2842&". 3b) if there is no parameter tail, try adding one. Lots of sites don't mind the extra "?random=4335" after the static URL. 4) submit the modified URL
Since the URL list is hashed, the code can only know if a URL is 'blocked' or 'not blocked'. It has no way to check if a URL is similar to a blocked URL.
Now - they *could* just pare the URL down to the host and test that. Or they could block by IP address. But you *can* examine the code to see if either technique is used. Also - if they are blocking by site, it is a lot easier to do a dictionary attack on the hashed list - and especially since DNS is a pretty good dictionary for this attack.
Slashdot Mirror
How do I handle buttons (i.e. graphics) with text on them?
You can use the background= feature of cells to place a background 'button' graphic in each table cell. As long as the cell is bigger than the graphic, the 'button' will float to the top left corner. Then use align (likely top and left) to get the text in the right spot. Be sure and use contrasting colors properly. Make the text part of an link, and away you go.
Fit and finish -- use CSS to suppress the decorations on the text, since it already looks like a button. Don't forget the ALT tags! Conveniently, you will also be text-enabling your pages.
All this applies whether you use a EN#FR#DE style inline in the page, or an exernal approach. The external approach works better if the text is unlikely to change often - things like a database access site, for example.
"Civilization advances by extending the number
of important operations which we can perform
without thinking about them."
--Alfred North Whitehead,
An Introduction to Mathematics
The artist gets paid the same way Slashdot gets paid - via that banner at the top of the page you just saw.
You count the click-throughs, but - just as with letters to the editor - every click-through represents so many thousand viewings of the banner. The sponsor is paying for the clicks, at some pre-determined CPM rate, knowing that everytime they pay 2.5 cents for a click, another 1000 or so also saw their sponsorship banner.
This isn't a lot different than bigmultinational!.com sponsoring the artist's tour in order to share in the attention that tour generates.
Of course, smart sponsors will put something really interesting and worth coming back to at the end of that link, not just another hi-I'm-a-sponsor page.
This, I think, is the core of the matter. It's also interesting that this is not, by and large, what the labels are saying. They're talking mainly about "artists' rights", while the artists figure they worked hard, and really ought to get paid, thank you.
So, I'll lay out the idea below again. I've run it through various discussion forums at mp3.com a couple of times, and nobody really noticed. I thought it was simple and straight-forward, but maybe it really is revolutionary...
First - you can't digitally protect music. If you encrypt it, then you have to decrypt it to use it, and unless you're using secure hardware, that protection won't last long. [see deCSS] You also can't use watermarks for that reason - if someone can identify the watermark, then they can remove it. You can identify music using watermarks, but only to determine that piracy and illegal distribution has taken place. You can't actually distribute the watermark check (see above). And if all else fails, someone will just digitize an analog copy.
It's beginning to look like it's digitally hopeless to try and protect music, until you realize that's not the goal. You just want to pay the piper. Literally.
Everyone's worrying about music distribution, but as MyMp3 and Napster show, the distribution problem is solved. We're just waiting on a little more bandwidth and disk space, and it will be solved for everybody forever. The distribution cost will be so low, that you would pay more to control the distribution than you would to actually distribute the content.
So, rather than worry about a solved problem, how can we pay the musician? The other time-honoured method of paying for music is pay-for-performance. This could be like a penny-an-hour radio station, but this ignores portable MP3 players and large hard drives. Last time I checked, I can't connect anywhere while I'm riding the subway.
The next step in the thought process is to let you store the music, but whenever possible, the player notifies ... well, it notifies someone of this selection. Ah, yeah, right. I don't want to think at all about the privacy aspects of that model. [see RealAudio]
The final ah-ha is realizing that I don't need to charge for all performances, or even most performances. I just need a good-enough sample of how often the music is selected. This, it turns out is easy.
First, you embed additional information in MP3 files - you can do this today without breaking existing MP3 players. [see MP3,ID3v2] We can squeeze in about 64K for the equivalent of about 4 seconds of audio - in other words, it's really inexpensive. In this 64K, you get about 3 or 4 sets of information. Each set is for one entity - the artist, the label, and (critically) one or more for sponsors. Each set has (a) a big banner advert, (b) a tiny banner advert, (c) a 16x32 black and white logo, (d) a name (ascii), and (e) a special URL.
Now, crank up that compiler, and go back to your open source MP3 player. When you encounter this block of data, display the appropriate chunk from the section. Try for the big banner, or just use the small one. Portable players with a graphic screen can go for the 16x32, and the really simple portable players will go with scrolling the name. Then cycle through each set, moving forward about once every 20 seconds. Finally - if someone selects the banner, logo, or name (by clicking - or whatever) then launch that special URL. Notice that the selection is clearly a user action - nothing happens unless the listener does something.
The URL is very special. It uniquely identifies the advert, and also uniquely identifies the tune. It could uniquely identify the original download as well, but that's up to the distributor. Before launch, the player will add the X and Y address of the click on a banner, and a hash code (with salt) of the following few seconds of music.
The server that receives the URL will redirect the user to something appropriate - artist, label, or sponsor - to what was clicked. If it is a sponsor, it records the click-through. But as it does the redirect, it notes the tune that it came from. That's all for the core technical stuff. The server itself would sensibly be the label's, but there's no concrete requirement for that.
Now look at the information stream you're getting. The number of click-throughs is going to depend on both how widely the file is distributed and how often it is listened to. These are the core attributes we want to measure for music popularity. In addition, since sponsors get a click-through, the artist and label can share a click-through revenue stream and an impression stream. As a final note, if you let the URL identify the specific download, then you can get loyalty points for downloading and distributing tunes to your friends.
So, did we achieve what we were after? I think so (but then, I'm biased). We have:
Conveniently, this is completely compatible with streaming MP3, so netradio works immediately and automatically generates the artists revenue stream. I don't think there will be a lot of pressure from artists and labels to penalize (or even regulate) netradio if it is going to automatically generate income.
Yes, you could strip out the information and pass on the file. But this has relatively little effect. With legitimate hyper-distribution it becomes very difficult for a pirate to get their works out to a lot of people.
Most conveniently, this is completely backward compatible with MP3. Artists could start adding sponsor info to downloaded MP3 tomorrow, and it won't affect properly built players. Once a large enough base of tunes exists, players can be reasonably expected to support the option. As a final nice touch, this can even move into the physical world, by including pre-encoded MP3s on the end of each CD, ready to move to the PC, stereo, or portable player.
So - final question. Would this model help solve some of the difficulties we're having here?
Then you should be able to bypass a number of
blocked URLs using the following workaround.
1) get the URL you are interested in
2) look at the tail of the URL
3a) if it already has parameters (there is a
"&" in there somewhere) sneak in your own
random parameter by replacing a single
"&" with "&random=2842&".
3b) if there is no parameter tail, try adding
one. Lots of sites don't mind the extra
"?random=4335" after the static URL.
4) submit the modified URL
Since the URL list is hashed, the code can only
know if a URL is 'blocked' or 'not blocked'. It
has no way to check if a URL is similar to a
blocked URL.
Now - they *could* just pare the URL down to the
host and test that. Or they could block by IP
address. But you *can* examine the code to see
if either technique is used. Also - if they are
blocking by site, it is a lot easier to do a
dictionary attack on the hashed list - and
especially since DNS is a pretty good dictionary
for this attack.