Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ranges for each analysis value #24

Open
Phyks opened this issue May 24, 2016 · 4 comments
Open

Ranges for each analysis value #24

Phyks opened this issue May 24, 2016 · 4 comments

Comments

@Phyks
Copy link
Contributor

Phyks commented May 24, 2016

Hi,

Maybe it could be useful to put the ranges of each analysis value (tempo, amplitude, frequency and attack) in the README.

Moreover, I was thinking about the way we compute distance and cosine similarity. The way we compute it at the moment kind of implies that each coordinate has the same weight, due to the implicit assumption that the basis (tempo, amplitude, frequency and attack) is orthonormal.

This means that an increase of 1 on the tempo value gives the same result as an increase of 1 of the amplitude value, in terms of distance.

I am not sure this is actually the case and maybe we should try to refine the formula.

@Polochon-street
Copy link
Owner

Hi,

You're right, and I'll add it to the readme as soon as I can
Regarding your concerns on the formula issue: you're completely right, as each of the computed values are is computed in quite an arbitrary way that is not really meaningful quantitatively. Though, I feel like computing the distance between the different points is the most logic way to do what we're trying to achieve.

We could also try some sort of weighted distance, but that'll need some trial and error; what do you think? Do you have something in mind?

@Phyks
Copy link
Contributor Author

Phyks commented May 25, 2016

Ok, that was what I feared.

The idea I had was to rescale every value to a given range (say [0, 1]). This would give an equal importance to every parameter, I am not sure if it is expected to be.

I am not sure neither if you can rescale every value to the given range.

Say for instance that you have a parameter which is tempo and that it is typically between 60 and 240, you could rescale with an affine transform so that 60 goes to 0 and 240 goes to 1.

@Polochon-street
Copy link
Owner

Polochon-street commented May 25, 2016

As I commented on some files, the end values are already scaled using an affine transform that I calibrated with a panel of ~10 calm songs and ~10 loud songs, so that all the parameter's values are between -4 and 4.
In practice, some are beyond [-4; 4], but the majority of songs will settle here.

We could multiply the end affine transform (for example, here https://github.com/Polochon-street/bliss/blob/master/src/amplitude_sort.c#L82) by 1/4 so that values range between [-1;1], but I'm not sure this will me useful.

Is that what you were thinking of?

I think in this current state, it is enough for the usage we have, but indeed it should be refined to have more « scientific » parameters. But given that music is a wide subject, I think it would need a whole thesis to cover how to accurately caracterize it :p

@Phyks
Copy link
Contributor Author

Phyks commented May 26, 2016

As I commented on some files, the end values are already scaled using an affine transform that I calibrated with a panel of ~10 calm songs and ~10 loud songs, so that all the parameter's values are between -4 and 4.
In practice, some are beyond [-4; 4], but the majority of songs will settle here.

We could multiply the end affine transform (for example, here https://github.com/Polochon-street/bliss/blob/master/src/amplitude_sort.c#L82) by 1/4 so that values range between [-1;1], but I'm not sure this will me useful.

Is that what you were thinking of?

Ah, I did not know they were all rescaled between -4 and 4. That seems ok then, as they all have the same interval of variations (and a scalar applied on every value does not do much).

I think in this current state, it is enough for the usage we have, but indeed it should be refined to have more « scientific » parameters. But given that music is a wide subject, I think it would need a whole thesis to cover how to accurately caracterize it :p

Sure =)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants