Dealing with .mp3 files..

[unsider]

I'm not quite sure if this would fall into PHP or MySQL help, but here goes.

 

When dealing with uploaded .mp3 files what is the best solution to storing them? Should I use a DB, specified directory, is there a way to archive and compress before storage without affecting quality.

 

I just want to know everything I can before I begin working on my project. If you have any articles, personal experience dealing with this type of thing, etc..

 

Thanks again.

[Lodius2000]

i would store the code needed to embed them or whatever your application is in mysql and store them in a folder in you site, this question comes up a lot about images, and the response always seems to be, store them in a folder, it cuts down on db bloat, removes the possibility of getting a truncated file because it has exceeded your blob size, makes querys faster... the list goes on

[unsider]

Thanks lodius. 

 

It's one of the things that is starting to really bother me, eventually I'm going to run out of server space even if I limited the upload size to 5MB, and in-terms of .mp3 quality is attrocious.

 

More opinions, ideas, corrections to my previous beliefs ...?

[unsider]

Ok I've done a little bit of reading while waiting for responses and I've come to a semi-conclusion.

 

The solution would be to read the mp3 binary and store it in a longtext, longblob, or blob row in a database, with two tables for info.

1. blob_id, blob_data, blob_timestamp, more (depending), etc..

2. .mp3 info ( artist, blob_id, file_size, timestamp, etc...)

 

Then I would retrieve the data from the database, etc.. and route them to a flash player.

 

Wallah!? Opinions on this solution, or is it a dud.

 

This is my first time dealing with .mp3 so go easy on me if it's an absurd solution.

[Lodius2000]

"eventually I'm going to run out of server space"

 

is your db space independent of your server space, if so then definately store the mp3s in the place with more space, but a 5mb mp3 takes up just as much space in a db as it does as a phisical file. BUT

 

i am going to swich from BLOB to TEXT because i know more about it

 

a TEXT field takes up 80 kb no matter what the size of the data entered in it contains. 120kb of text stored in a TEXT field will truncate after 80kb, 80kb of text will store all of the text, 1kb of text will store 1kb of text and 79 kb of NULL data, so regardless of the data size to be stored, 80 kb will be stored, so if the same is true for blob, which i think it is, your max blob size will be used for every stored mp3, soooooo a 3 megger will take up the same as a 1 megger so if your db is infinite storage and your server is not, use the db, if your server space and db are linked (which i bet they are) the db method will kill your server space faster because it is using the max filespace fore every upload

 

anyone, If i am wrong call me on it

 

thanks

[Zejom]

"eventually I'm going to run out of server space"

 

is your db space independent of your server space, if so then definately store the mp3s in the place with more space, but a 5mb mp3 takes up just as much space in a db as it does as a phisical file. BUT

 

i am going to swich from BLOB to TEXT because i know more about it

 

a TEXT field takes up 80 kb no matter what the size of the data entered in it contains. 120kb of text stored in a TEXT field will truncate after 80kb, 80kb of text will store all of the text, 1kb of text will store 1kb of text and 79 kb of NULL data, so regardless of the data size to be stored, 80 kb will be stored, so if the same is true for blob, which i think it is, your max blob size will be used for every stored mp3, soooooo a 3 megger will take up the same as a 1 megger so if your db is infinite storage and your server is not, use the db, if your server space and db are linked (which i bet they are) the db method will kill your server space faster because it is using the max filespace fore every upload

 

anyone, If i am wrong call me on it

 

thanks

No. To put it very simply, blob is a giant varchar.

[Lodius2000]

oooooohhhhhh

[tibberous]

I would just store the path to files. You can't compress them without loosing quality, but you can use ffmpeg if you find it's worth the tradeoff. The system I wrote compresses at different bitrates, then gives the end user the option which to play.

[unsider]

More opinions?

 

The more perspectives/ideas, the better.

 

Sorry for being so persistent about this, I'm trying to discover  solution as quickly as possible so I can begin working. Unfortunately I can't find any real proof, ie. a properly designed audio website's developer's opinion on this subject.

[unsider]

I've gone up and down google, and I'm very disappointed to report that I can't find any solid information as to how this can be done effeciently.

 

Newgrounds.com has a nice little set-up similar to what I'd like to do so I'm PMed a few admin there who might be able to help me out, but I've found a few other things as well.

 

A consensus was made amoung a few of the articles I read, and that is:

Not to store the actual .mp3 in the mySQL DB, but rather, store the .mp3 somewhere else on your server, and just store the path in the database. And then call it.

 

Well, where else on the server are they suggesting I save it?

 

Any opinions at all, this is driving me crazy.

 

 

 

One more solution:

 

store the files themselves in your fs, then create the logic with the db, for example I would have the path, filename and tag info in a db and the files on the fs, then I could use the db for logic with the interface...

 

*shrug*

[tibberous]

But why do you want them in the database? I don't see the advantage, when you can just put them in as files and link them... and then your free to reencode them through the commandline - ffmpeg isn't going to reencode stuff you have stored in a database.