Re: [Audacity-devel] Find Notes mode
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Andreas M. <And...@gm...> - 2007-11-24 14:03:13
|
Hallo James! > I can see you're excited and enthusiastic. Be aware that making new > file formats is a significant step; File formats take a while to settle > down, if not designed carefully at the outset. This can cause problems > for us if we commit to supporting them in future, since Audacity then > has to cope with 'all versions'. > Oh, I wont need to invent any new file format so soon, I think. I just use an Audacity project, where I load in all instruments samples, by using Import. I've added UpdateInstruments() to AudacityProject, which immediately returns if this is not the project, that's selected as instrument db, otherwise iterates through all Tracks and calls Track::UpdateInstrument(). In Track::UpdateInstrument() I call Instrument::Update(), which computes the FFTs and searches the maxima, planned to use them later as hash values. > What information do you want to store for each instrument? > At the moment, I can wait for the computations. But if I really go beyond hundreds of instruments, I'd had to invent a DB file format, that's true. At the moment I'm just experimenting with two instrument samples, which I have so far: an A from my guitar and an A of my voice. > I'm interested in this kind of sound database too, more from the > perspective of speech analysis. What information is needed to classify > a vowel sound as an 'ooh' or an 'aah'?? it's more than just having a > sample spectrogram to compare with, isn't it? I'm not sure about this. In the FFT all information is in which is in a time domain signal. > ...and then on from there > linking in to speech synthesis and speech recognition. > I believe it's a kind of fingerprint, consisting out of the relevant maximum data. So one has to find the frequency and volume of the maxima. Those could be quantized to limit the search tables and used as hash keys. ;-) > Do some googling and see if there is a format around already that could > be reused. Also consider the GUI - If there are a 100 instruments we > might want to organise them in various ways (wind, string, percussion) x > (base, treble) and see spectrograms of representative sounds.... I know > you may only be thinking of a couple of instruments at the moment, but > think about possible paths by which the feature could grow. You're more > likely to get other people contributing to it too if it has a natural > way to extend. > Yeah, I know. That's why I chose an Audacity project for my instruments database. I also had some trouble with Import, so this idea saved me a lot of headaches. :-D When Audacity will expand, the GUI will hopefully provide a tree view some time in near future, with all the tracks accessible, and be able to minimize the tracks (not display it at all, only as text in the tree). > The alternative is to just go ahead in an extreme programming style, > avoiding design up front. In that case your database (at this stage) > probably amounts to pointing Audacity at a folder that contains clips of > the instruments you're interested in without making any new file format. > Yes, this was my first attempt! But I choose Instruments.aup as being very nice to me. Cheers, Andreas |