venta

Yes, I'm rapidly reaching the conclusion that you and Onebyone are right about the modular arithmetic.

However, it's actually surprising how few cases it's making any difference - often it doesn't matter, because I only have one album to choose from, but quite often (for track numbers) it turns out that modular arithmetic and arbitrarily-choose-last provide the same answer :)

Think I'll go modular from now on, though.

From:

In which case, to avoid any [mathematical] bias we should submit album and track numbers in a very large range. In the case of track numbers, for example, if I submit values in the range 1 to 20 and you modulo that value with the actual number of tracks, I will end up chosing lower numbered tracks more often than higher ones. But if I chose tracks in the range 1 to 1000000 that bias will almost completely disappear.

From:

Yeah, I don't really like that approach, though. Which was another reason why I was trying to steer clear of modular stuff in the first place - I wanted to encourage people to aim for a "likely" track number. But that just meant that I was going to end up with more last tracks than I ought.

I haven't yet thought of a nice, elegant solution to this. Maybe I should hone my collection down to contain only CDs with, say, exactly twelve tracks.

From:

If they pick too large a number (either for the CD or for the track), you simply carry on counting into the next group?

Of course, in that case, you're effectively combining everything into a single list of several thousand tracks, and a single index number into that list would suffice.

From:

Of course, in that case, you're effectively combining everything into a single list of several thousand tracks, and a single index number into that list would suffice.

Aaaargh!

<cower>

Look, my entire concept of the music I own is (primarily) artist-based, and secondarily album-based. I'm trying to break myself gently into this random playlist idea. Stop trying to scare me!

From:

find . -name "*.mp3" | cat -n

will give you a nice numbered list of all your mp3 files. Then all we have to do is chose a number from that list.

From:

I know. I use find as well :)

I just don't want to think of my mp3s as a big floppity linear list. Their album structure is important, dammit :)

From:

<splutter> but surely not if we're putting together a playlist of random tracks from random albums?!

From:

I think what she's doing is the same thing my Dension does for generating random play lists: at each point in the directory structure, pick a random entry. If it's a file, play it. If it's a directory, repeat the random selection. After each play, start again at the top of the structure.

Of course, this produces effect unfairly biasing towards directories which are under-represented.

(Consider two directories. There's an even choice between them. But one contains only one track, and the other contains 10 tracks. So 50% of the choices will turn out to be that first track, and the other ten only get an expectation of 5%)

From:

find . -type t, unlike dir /s only generates a list of files. So using this method will produce no bias.

From:

no bias

Yes, where the original selection method does include bias: each of

venta's artists only have 1 chance in 262 of being selected to supply a track, even if one of those artists has produced half of her actual mp3 collection.

From:

the original selection method does include bias

It was meant to. I have, for example, five directories of New Model Army mp3s, and only one directory of Baader Meinhof.

This does not mean I want Baader Meinhof to appear in the playlist only one fifth as often as NMA does.

From:

Ah yes, good point.

Which _may_ have been a desirable attribute of her original method, of course. Venta may wish to have her "random" playlist contain an even mix of artists and not be biased towards an artist she has a lot of. Although usually the most represented "artist" in a collection is "VARIOUS ARTISTS" (ie compilations) and so this probably isn't the case.

Which, er, I think leads me to conclude that the big floppity list is well suited to producing this random selection.

I wonder if Venta ever wonders why she bothers starting these threads. ;-)

From:

I think I know why she starts them.
I wonder whether she ever wonders how to stop them. :)

From:

I wonder if Venta ever wonders why she bothers starting these threads. ;-)

Hey, I only start them, you don't think I read them, do you ?

From:

Would "No" be the right answer?

From:

It had occured to me that you probably didn't want to flatten the list, and this might be classed as an unfortunate side effect to a "reasonable" workaround.

The find is, in fact, even worse, as it doesn't traverse the file structure in alphabetical order, but in inode order(*). So traverses each directory in approximately chronological order(*). And therefore even more floppity than you'd expect.

(*) I think.

From:

Well, it would only be a list produced for the purpose of randomly selecting tracks. The directory structure itself would be untouched. With the list Venta could then simply ask "pick a number between 1 and n", and go an look up the track that the chosen number represented.

From:

I know, but you'd kind of expect there to be some logical connection between track N and track N+1. Which there would be, as long as they're within the same directory (due to find being depth first). But you'd get great discontinuities as you crossed directory boundaries: my machine starts with U2, and then jumps to ABC (thus disproving my chronological theory, anyway).

On the other hand, given that it's the musical style that's important, the jump from "Peter Skellern" to "Suede" and then to "Percy Sledge", whilst being gradual in a lexicographical sense (note, I store them surname first!) is somewhat more disturbing when you actually listen to them.

Which proves that my point is still bobbins :)

From: