Storing wave files in database

[nicolasr]

Hi,

in my current project I need to record audio data
analyse them and store everything in some sort of database.

I have not much experience with databases except for
some small tests with ADO and MS Access, MySql
and Paradox.

The goal is to record sample files for test speakers
and store the audio data, name and gender of the speaker
and finally some analysis results. All this would happen on
a local computer Win2K/XP. Network access, if needed
at all, would be limited to a few users.

My questions:

1) Can anyone give some advice as to whether it is reasonable
to store large amounts of binary data in a database, wave files
in my case? Or should I store file paths to external wave files?

2) In case I use an MS Access database: is there a limit on how
many data I can store in it? The number of records wouldn't be
that large but the total amount of data could be well beyond 2 GB.

3) Are there any performance issues in reading/storing large amounts of
binary data from a database compared to file access for external referenced
files? How about MS Access in particular?

4) If all of the above is absolutely nonsense, does anyone have any
experience what a good solution would be for this task?

thanks for any comment,
Nicolas

 

[Cor Ligthert [MVP]]

Nicolasr.

1) Can anyone give some advice as to whether it is reasonable
to store large amounts of binary data in a database, wave files
in my case? Or should I store file paths to external wave files?

I have no expirience with wave. However as it is probably the same as for
images, would I not keep it in the database, however as apart files. My
expirience with large blob images is that it takes at the moment still non
acceptable time.

2) In case I use an MS Access database: is there a limit on how
many data I can store in it? The number of records wouldn't be
that large but the total amount of data could be well beyond 2 GB.

I think that this is to much for a DataBase field to access in a correct
way.
SQLExpress a database is limited by to a maximum of 4GB. However probably
will everybody tell you that you are a fool if you try to do this with
Access (the real name is a Jet) database.

3) Are there any performance issues in reading/storing large amounts of
binary data from a database compared to file access for external
referenced
files? How about MS Access in particular?

You will find it very quick slow, as you have expiriences with any kind of
SQLserver.

4) If all of the above is absolutely nonsense, does anyone have any
experience what a good solution would be for this task?

I would first try SQLExpress, however with pointers to a folder for those
hug files.

http://msdn.microsoft.com/vstudio/express/sql/

Just my thoughts,

Cor

 

[Hendrik]

As said above - stay far away from Access. I have an Access database
(from hell) which is only 500MB.
I would use the MSDE (or SQLExpress) - store only the paths of the
files and related data in the DB, save the actual files on the HDD.

 

[Vayse]

Hi,

in my current project I need to record audio data
analyse them and store everything in some sort of database.

I have not much experience with databases except for
some small tests with ADO and MS Access, MySql
and Paradox.

I think MS Access will do you fine. Unless you are planning to store overa
million different sounds, it should suit you.
You don't store the Wave files in the database. Leave them on your local
hard drive, or network hard drive.
In your database, you would store the path to the wave file. Heres a sample
of what I mean
SoundID Name FilePath
1 Humming Bird C:\Sounds\Humming.Wav
2 Bass Test C:\Sounds\BassText.Wav

So the user scrolls through your data, in a form you design. Then add a
button to your form to play the file.
It would have code like: fHandleFile(FilePath, WIN_NORMAL)

I've posted the code for fHandleFile below. This code will open the file,
using whichever program your PC is configured to use.
The code is in Visual Basic 6.
Regards
Vayse


'************ Code Start **********
' This code was originally written by Dev Ashish.
' It is not to be altered or distributed,
' except as part of an application.
' You are free to use it in any application,
' provided the copyright notice is left unchanged.
'
' Code Courtesy of
' Dev Ashish
'
Private Declare Function apiShellExecute Lib "shell32.dll" _
Alias "ShellExecuteA" _
(ByVal hwnd As Long, _
ByVal lpOperation As String, _
ByVal lpFile As String, _
ByVal lpParameters As String, _
ByVal lpDirectory As String, _
ByVal nShowCmd As Long) _
As Long

'***App Window Constants***
Public Const WIN_NORMAL = 1 'Open Normal
Public Const WIN_MAX = 3 'Open Maximized
Public Const WIN_MIN = 2 'Open Minimized

'***Error Codes***
Private Const ERROR_SUCCESS = 32&
Private Const ERROR_NO_ASSOC = 31&
Private Const ERROR_OUT_OF_MEM = 0&
Private Const ERROR_FILE_NOT_FOUND = 2&
Private Const ERROR_PATH_NOT_FOUND = 3&
Private Const ERROR_BAD_FORMAT = 11&

'***************Usage Examples***********************
'Open a folder: ?fHandleFile("C:\TEMP\",WIN_NORMAL)
'Call Email app: ?fHandleFile("mailto:[email protected]",WIN_NORMAL)
'Open URL: ?fHandleFile("http://home.att.net/~dashish", WIN_NORMAL)
'Handle Unknown extensions (call Open With Dialog):
' ?fHandleFile("C:\TEMP\TestThis",Win_Normal)
'Start Access instance:
' ?fHandleFile("I:\mdbs\CodeNStuff.mdb", Win_NORMAL)
'****************************************************

Function fHandleFile(stFile As String, lShowHow As Long)
Dim lRet As Long, varTaskID As Variant
Dim stRet As String

'First try ShellExecute
lRet = apiShellExecute(hWndAccessApp, vbNullString, _
stFile, vbNullString, vbNullString, lShowHow)

If lRet > ERROR_SUCCESS Then
stRet = vbNullString
lRet = -1
Else
Select Case lRet
Case ERROR_NO_ASSOC:
'Try the OpenWith dialog
varTaskID = Shell("rundll32.exe shell32.dll,OpenAs_RunDLL "
_
& stFile, WIN_NORMAL)
lRet = (varTaskID <> 0)
Case ERROR_OUT_OF_MEM:
stRet = "Error: Out of Memory/Resources. Couldn't Execute!"
Case ERROR_FILE_NOT_FOUND:
stRet = "Error: File not found. Couldn't Execute!"
Case ERROR_PATH_NOT_FOUND:
stRet = "Error: Path not found. Couldn't Execute!"
Case ERROR_BAD_FORMAT:
stRet = "Error: Bad File Format. Couldn't Execute!"
Case Else:
End Select
End If
fHandleFile = lRet & _
IIf(stRet = "", vbNullString, ", " & stRet)
End Function

 

[Paul Clement]

On Wed, 29 Mar 2006 02:16:55 +0200, "nicolasr" <nicolasrNOSPAMATSIGNgmx.net> wrote:

¤ Hi,
¤
¤ in my current project I need to record audio data
¤ analyse them and store everything in some sort of database.
¤
¤ I have not much experience with databases except for
¤ some small tests with ADO and MS Access, MySql
¤ and Paradox.
¤
¤ The goal is to record sample files for test speakers
¤ and store the audio data, name and gender of the speaker
¤ and finally some analysis results. All this would happen on
¤ a local computer Win2K/XP. Network access, if needed
¤ at all, would be limited to a few users.
¤
¤ My questions:
¤
¤ 1) Can anyone give some advice as to whether it is reasonable
¤ to store large amounts of binary data in a database, wave files
¤ in my case? Or should I store file paths to external wave files?
¤

Security and portability are typically the reasons for storing the binary data in the database. If
neither is really a requirement then file paths would be much more efficient. Of course you can
still implement NTFS file security as well to limit access to the files.

¤ 2) In case I use an MS Access database: is there a limit on how
¤ many data I can store in it? The number of records wouldn't be
¤ that large but the total amount of data could be well beyond 2 GB.
¤

Access probably isn't a very good solution for this (unless you use file paths). WAV files can be
quite large so given the potential size of the database you will run up again the two gig limitation
rather quickly.

¤ 3) Are there any performance issues in reading/storing large amounts of
¤ binary data from a database compared to file access for external referenced
¤ files? How about MS Access in particular?
¤

Sure. There will definitely be overhead when storing the files in the database. Unless your WAV
files are on average under ten seconds in length (16-bit stereo, 44.1 k) the overhead can be quite
substantial.


Paul
~~~~
Microsoft MVP (Visual Basic)

 

[nicolasr]

thanks to all for your suggestions and informations.
That was really of great help.
I think I'm now able to find the best compromise.

Nicolas