mchwasisdj
Hi, I think each file having its own data is very beneficial. I mean if info like poi could be tagged the same way that common tags do or embedded in some other way, it would be superb. The problem with having a centralized db is that
1. For large dbs, the system becomes slow especially when launching vdj for the first time and also the general stability of the vdj is reduced when running.
2. Reduced flexibility. This occurs when you split the db into smaller chunks like analyzing each genre separately. This way each time you prepare for a gig you have to use that specific db and incase during the gig a random request is made you will have to mix blindly since that song may not be in your prepared db for that gig and even if you carried that db it would take a minute to change the db which may not be a good idea after all.
Also every time you add new songs you have to look for specific db in order to update.
If each song can have its own data all the problems are solved. Once you analyze, set your poi and tags that's it. Even migrating from one machine to the next will be easier, you just have to copy the songs.
The only remaining thing would be to add settings to manage the functionality eg choosing to write info to centralized db or write directly to individual songs or both and also which db info to use.
1. For large dbs, the system becomes slow especially when launching vdj for the first time and also the general stability of the vdj is reduced when running.
2. Reduced flexibility. This occurs when you split the db into smaller chunks like analyzing each genre separately. This way each time you prepare for a gig you have to use that specific db and incase during the gig a random request is made you will have to mix blindly since that song may not be in your prepared db for that gig and even if you carried that db it would take a minute to change the db which may not be a good idea after all.
Also every time you add new songs you have to look for specific db in order to update.
If each song can have its own data all the problems are solved. Once you analyze, set your poi and tags that's it. Even migrating from one machine to the next will be easier, you just have to copy the songs.
The only remaining thing would be to add settings to manage the functionality eg choosing to write info to centralized db or write directly to individual songs or both and also which db info to use.
Inviato 2 days ago @ 3:44 pm
mchwasisdj
Ooh shit. On second thought, don't tell me it's not possible due to copyright grounds. Even if it is so, why not add the ability to read that info from songs so that the users are responsible for adding the data by themselves? Yours is just to read/extract.
Inviato 2 days ago @ 4:00 pm
Adion
What size of library are we talking about?
Since you mention it slows down virtualdj startup, I assume millions of tracks?
If so, imagine how slow opening vdj would be if it would have to read all the information from all these tracks from all these millions of tracks on opening, instead of only the database.
Since you mention it slows down virtualdj startup, I assume millions of tracks?
If so, imagine how slow opening vdj would be if it would have to read all the information from all these tracks from all these millions of tracks on opening, instead of only the database.
Inviato yesterday @ 4:26 am
mchwasisdj
But for this case I presume the info will only be read when one loads the song on the deck or isn't that so? Since what is the point of parsing all the songs when in reality you won't play all of them?
Inviato yesterday @ 6:37 am
mchwasisdj
Huh not millions of songs but I have noticed slow startups on my budget laptop when I have dbs of more than 3mb on it. Don't get me wrong, when I say slow stratups I don't mean like really slow. You just notice the machine struggling alittle bit.
Inviato yesterday @ 6:47 am
locoDog
yeah that doesn't work when searching does it?
Inviato yesterday @ 6:49 am
mchwasisdj
Damn! You are right but that is the downside of it. On the contrary, I think a feature like that would be great for backups. In that if you loose your db for some reason you have another source of truth and all you need to do is scan and regenerate the main db. I know vdj also does backups but here I'm assuming the worst case scenario.
Inviato yesterday @ 6:55 am
mchwasisdj
Huh that search argument was eye opening, I honestly didn't think of that. So I guess I'll be posting about search feature after all. I have some suggestions that I think would be great since the current one is quite limited in my opinion.
Inviato yesterday @ 7:10 am
PhantomDeejay
Also you didn't understand the point Adion was trying to make..
Reading (and writing) information on multiple files will always be slower than reading and writing one big, even HUGE, even HUMONGUS file.. ;)
Reading (and writing) information on multiple files will always be slower than reading and writing one big, even HUGE, even HUMONGUS file.. ;)
Inviato yesterday @ 8:21 am
mchwasisdj
Thanks, point noted.
Inviato yesterday @ 8:24 am