Begin forwarded message: > From: David Viens > Date: 31 July 2004 13:47:54 IST > To: libsndfile-devel@mega-nerd.com > Subject: [libsndfile-devel] Re: Overview file format > Reply-To: libsndfile-devel@mega-nerd.com > > Hi there > > ahh great subject, i was just refining my waveform display code and > retouching my > overview file format :) > I somewhat proposed a format to Ross Bencina (audiomulch) and Bram > (smartelectronix) > a while ago calling it "musicdspeaks" as a joke, and did a very > simple GLUT -based display of it, doing clock cycle checks on each > display calculations based > on sample blocks sizes for peak values (min and max) for each of these > cases: 16,32,64,and 128samples. > While ive never thought of interleaving RMS in there, im not closed to > the idea. > (bram used pieces of my algos in his sm(ex)oscope VST plugin somewhat, > but i dont know to which extents) > > My findings: > 1)Inserting min,max,min,max....(...)min.max creates a supplemental > burden > on the drawing code. instead, if you insert the min max values in the > ORDER in which they were found in a > say 32 sample chunk, then you can easily draw a line segment from each > point to each point in one go > so in realilty, depending on the source data the peac can become > max,min,min,max, (..) you get the idea. > no loss of info there, you even GAIN some imho., whether you draw the > waveworm this way or differently. > > 2)setting min and max values with "char" size is enough for me. (and > by comparing my wavedisplay > with the ones in some major vendors), this is allready an "average" of > the real signal, and the size of a waveform display > in tyhe y axis is seldom very big in a multitrack view.. its quite > often decimated. > (yes ive tried with 16 bit values did screenshots and wasnt impressed > - however i _was_ by the > size of the files! double, quadrupling peak files, for no visible > improvements > > Idd loved to clean up my example GLUT code and share it > , but im going away for two days.. It is bigendian unfriendly atm. Ill > fix it and share it monday > > In any case, nothing is set in stone in my current desing and its the > right time to improve it. > Im all for a libsndfile solution, and some compromises. Its a great > news for the community. > at last having some form of open peak file format! > > (but idd prefer RMS and peaks to be two separate files, optionaly > generatable by libsndfle.) > > Thanx guys. > (sorry my coffee might not be totally in my veins yet)... > > > > > -- > David Viens, Plogue Art et Technologie Inc. > Montreal. http://www.plogue.com > ------------------------------------------------------------ > libsndfile-devel Mailing List > To unsubscribe: > > > From: David Viens > Date: 2 August 2004 14:38:49 IST > To: libsndfile-devel@mega-nerd.com > Subject: [libsndfile-devel] Re: Overview file format > Reply-To: libsndfile-devel@mega-nerd.com > > Hi there > > Ok heres the simplistic GLUT sample that displays a > single raw 16 bit PCM mono waveform using my peaks method: > > http://plogue.com/davidv/waveview.tar.gz > > This contains sources, and precompiled win32 and osx exe. > I didnt have time to create proper makefiles for un*x's but its only 3 > cpp files. > It also contains a test sound file "test.raw" that you can use. > >> From my cpu calculations, id say that either 32 or 64 samples for >> min,max pair > does a good job. I have excel graphs of CPU vs zoom ratio, (with and > without using peaks) > but they are only at work. (and im in vacation atm) > > to try other peak sizes change this: > #define TESTSIZE 64 > (but if you load a mdspk file , its going to use what it was created > with) > > usage: > > waveview -r test.raw (reads test.raw and READ test.raw.mdspk > waveview -w test.raw (reads test.raw and WRITES test.raw.mdspk) > > Im currently starting to code this properly with !power of two > interpolations > under wxWindows. (but this will be closed source :) > > > -- > David Viens, Plogue Art et Technologie Inc. > Montreal. http://www.plogue.com > ------------------------------------------------------------ > libsndfile-devel Mailing List > To unsubscribe: > > Begin forwarded message: > From: Juhana Sadeharju > Date: 3 August 2004 06:30:26 IST > To: libsndfile-devel@mega-nerd.com > Subject: [libsndfile-devel] Re: Overview file format > Reply-To: libsndfile-devel@mega-nerd.com > >> From: Erik de Castro Lopo >> >> I actualy think it should be part of the libsndfile API so that >> all users have the same API for generating and reading the overview >> data. > > OK. > >> - When a file is opened for read, a call to the overview create >> function will search for an existing overview file and use that >> if it is correct or create a new one. > > You must mean "after a file is opened" because not every app needs > the overview files. "When" could be too much. > >> - To check that an existing overview file is correct, the overview >> file header will contain a hash of the the first say 256 bytes >> of the file it is supposed to be an overview of. > > md5sum could do fine too. > > Applying effects may not change the header. > How about using file times as well or alone? > > But all that could be too much. > >> - When generating an overview file from an existing file, >> libsndfile will provide a way for the calling application to >> provide a progress bar for user feedback. This will probably >> be done using a callback function. > > Could be too much. > libsndfile could only provide file routines for the overview format > in the first place. > >> - When a file has been opened and an overview file is being used, >> the overview data will be cached in memory (under the control >> of libsndfile) and libsndfile will provide an API for accessing >> it. > > Could be too much. > >> For the write case, I think don't think it really makes sense to >> generate an overview file one-the-fly. > > Audacity displays the recorded audio immediately, i.e., Audacity > generates the overview data on-the-fly. > > Also, when effects are applied at background, it is better to > generate the overview at the same time, i.e., user see only one > progress bar. > > > I suggest we keep it simple for now. We could now agree about the > header and the filenames. We could write a libsndfile function which > returns the filenames of the found overview files for the given > audiofile. We could write open(), read(), write(), close() routines. > > Even the applications knows the overview data format, we could > provide the routines which generates the overview data for the given > audio. > > We could now sketch the miniapplication as an example. > > Juhana > -- > http://music.columbia.edu/mailman/listinfo/linux-graphics-dev > for developers of open source graphics software > ------------------------------------------------------------ > libsndfile-devel Mailing List > To unsubscribe: > > Begin forwarded message: > From: Erik de Castro Lopo > Date: 4 August 2004 08:10:54 IST > To: libsndfile-devel@mega-nerd.com > Subject: [libsndfile-devel] Re: Overview file format > Reply-To: libsndfile-devel@mega-nerd.com > > On Tue, 3 Aug 2004 08:30:26 +0300 > Juhana Sadeharju wrote: > >> You must mean "after a file is opened" because not every app needs >> the overview files. "When" could be too much. > > Yes, after the file is opened and the application tries to open an > overview file. > >>> - To check that an existing overview file is correct, the overview >>> file header will contain a hash of the the first say 256 bytes >>> of the file it is supposed to be an overview of. >> >> md5sum could do fine too. > > Probably too CPU and I/O heavy for files of a gigabyte or more. > >> Applying effects may not change the header. >> How about using file times as well or alone? > > A combination of file modification time and a hash of first 256 bytes > of the file should be sufficient. > > > >>> For the write case, I think don't think it really makes sense to >>> generate an overview file one-the-fly. >> >> Audacity displays the recorded audio immediately, i.e., Audacity >> generates the overview data on-the-fly. > > Thats a good point for the file read case and something to think > about for the file write case. > >> Also, when effects are applied at background, it is better to >> generate the overview at the same time, i.e., user see only one >> progress bar. > > OK, more evidence that overview generation on file write is > worthwhile. > >> I suggest we keep it simple for now. > > Simple yes, but not so simple that the API needs to be modified > later. > >> We could now agree about the header and the filenames. > > For a demo mini-application yes, but I think its premature to > put any of this into libsndfile yet. > > Erik > -- > +-----------------------------------------------------------+ > Erik de Castro Lopo nospam@mega-nerd.com (Yes it's valid) > +-----------------------------------------------------------+ > "Python addresses true pseudocode's two major failings: that it > isn't standardized, and it isn't executable." > - Grant R. Griffin in comp.dsp > ------------------------------------------------------------ > libsndfile-devel Mailing List > To unsubscribe: > > Begin forwarded message: > From: Erik de Castro Lopo > Date: 4 August 2004 08:24:53 IST > To: libsndfile-devel@mega-nerd.com > Subject: [libsndfile-devel] Re: Overview file format > Reply-To: libsndfile-devel@mega-nerd.com > > On Wed, 4 Aug 2004 10:02:52 +0100 > Simon Burton wrote: > >> I honestly don't see why libsndfile should support this. > > There are currently at least 5 sound file editors that I know about > that use libsndfile. My guess is that all of the developers of the > about have been thinking of / wishing for / have written an overview > file format. Putting this in libsndfile prevents replication of > effort which was the main reason libsndfile's was started. > >> Unless there is some >> standard overview format/header info that I don't know about. > > If this is done right, then at least among the editors that choose to > use it this will be the standard. > > >> It seems that apps that do need this (NLEs) will need much more >> trickery, >> tightly integrated with the editing process. Are there other use >> cases I am missing ? > > NLEs usually do mostly non-destructive editing (ie source file is > never modified). A such, the overview file is useful until the > parent file is deleted. > >> Surely this is a hassle for GUI programmers ? They will have to create >> another thread to run the generate function. > > GUI programers worth their salt are already running separate threads > when scanning a file for waveform drawing. The generate function > can run in the same thread. > >> It's also tricky to do from, say, a python wrapper. > > I would actually thing that a Python program would have very little > use for this functionality (apart from completeness). How many people > are writing GUI apps with waveform viewing in Python? > >> Much easier (but maybe not for Erik) would >> be a >> >> int poll_generate_overview( ??? ) >> >> that returns some kind of status. > > That means one of two things: > > - Libsndfile has to be multi-threaded which is a bad idea for > all sorts of reasons (portablity of pthreads/interaction with > fork()/signals etc). > - The overview file is only generated during the > poll_generate_overview() function. > > The second option is acceptable and not much more work than my original > suggestion. > >> Maybe it could even allow >> access to the partially generated overview data, which provides >> more interesting progress information to the user. > > Indeed. > > Erik > -- > +-----------------------------------------------------------+ > Erik de Castro Lopo nospam@mega-nerd.com (Yes it's valid) > +-----------------------------------------------------------+ > "A subversive is anyone who can out-argue their government" > ------------------------------------------------------------ > libsndfile-devel Mailing List > To unsubscribe: > > Begin forwarded message: > From: Magnus Hjorth > Date: 4 August 2004 09:52:50 IST > To: libsndfile-devel@mega-nerd.com > Subject: [libsndfile-devel] Re: Overview file format > Reply-To: libsndfile-devel@mega-nerd.com > > > My editor reads the first 128 samples belonging to each pixel and > calculates min/max values on the fly. This works well even for large > files, so I don't really see the need to store anything on disk just > to speed up drawing. > > OTOH, if people want it and it doesn't disturb the rest of the library > there's no reason to complain. > > /Magnus > ------------------------------------------------------------ > libsndfile-devel Mailing List > To unsubscribe: > > Begin forwarded message: > From: Simon Burton > Date: 4 August 2004 10:02:52 IST > To: libsndfile-devel@mega-nerd.com > Subject: [libsndfile-devel] Re: Overview file format > Reply-To: libsndfile-devel@mega-nerd.com > > On Sat, 31 Jul 2004 10:33:33 +1000 > Erik de Castro Lopo wrote: > >> Hi all, >> >> Juhana Sadeharju contacted me via private email with a suggestion >> that libsndfile be extended to include a file overview format. > > I honestly don't see why libsndfile should support this. Unless there > is some > standard overview format/header info that I don't know about. > It seems that apps that do need this (NLEs) will need much more > trickery, > tightly integrated with the editing process. Are there other use > cases I am missing ? > > ... >> I've now had a little more time to mull this over. To flesh this idea >> out a little more, the overview file has the following top-level >> requirements for the file read case: >> > ... >> >> - When generating an overview file from an existing file, >> libsndfile will provide a way for the calling application to >> provide a progress bar for user feedback. This will probably >> be done using a callback function. > > Surely this is a hassle for GUI programmers ? They will have to create > another thread to run the generate function. It's also tricky to do > from, say, a python wrapper. Much easier (but maybe not for Erik) would > be a > > int poll_generate_overview( ??? ) > > that returns some kind of status. Maybe it could even allow > access to the partially generated overview data, which provides > more interesting progress information to the user. > > Simon. > > -- > Simon Burton, B.Sc. > Licensed PO Box 8066 > ANU Canberra 2601 > Australia > Ph. 61 02 6249 6940 > http://arrowtheory.com > ------------------------------------------------------------ > libsndfile-devel Mailing List > To unsubscribe: > > Begin forwarded message: > From: Erik de Castro Lopo > Date: 4 August 2004 10:22:35 IST > To: libsndfile-devel@mega-nerd.com > Subject: [libsndfile-devel] Re: Overview file format > Reply-To: libsndfile-devel@mega-nerd.com > > On Wed, 4 Aug 2004 10:52:50 +0200 > Magnus Hjorth wrote: > >> >> My editor reads the first 128 samples belonging to each pixel and >> calculates min/max values on the fly. This works well even for >> large files, so I don't really see the need to store anything on >> disk just to speed up drawing. > > I just thought it might be worthwhile doing some back-of-the-envelope > calculations here. > > Lets assume you are drawing for a screen size which is 1024 pixels > wide and lets assume that we have a 4 Gigbyte file (definitely not > the largest file libsndfile can handle). Now if we assume that the > file contains a single channel of 16 bit audio we have about 2 > million samples. > > Under your scheme, you will end up drawing your fully zoomed out > view using 128 samples out of each 1950 (2e6/1024) samples. > > Now lets look at another example. Consider a recording of a 5 string > bass guitar with a lowest string being tuned to the B (46Hz) below > the low E of a 4 string bass guitar. Sampled at 48kHz, this low B > has a wavelength of about 1040 samples (48000/46). > > In both cases, your scheme misses large amounts of what is actually > there. If you choose to use it, the overview file format can avoid > both of these problems with less work on your part. > > Erik > -- > +-----------------------------------------------------------+ > Erik de Castro Lopo nospam@mega-nerd.com (Yes it's valid) > +-----------------------------------------------------------+ > "I've got an idea! Sun, Oracle, and IBM hold down MS while Linux > gets to kick them!" -- Lou Grinzo on LinuxToday.com > ------------------------------------------------------------ > libsndfile-devel Mailing List > To unsubscribe: > > Begin forwarded message: > From: Magnus Hjorth > Date: 4 August 2004 11:01:14 IST > To: libsndfile-devel@mega-nerd.com > Subject: [libsndfile-devel] Re: Overview file format > Reply-To: libsndfile-devel@mega-nerd.com > > > Yes, since I don't read everything I will obviously miss a bit of info > and get poor information on low frequencies, but it's fast and works > good enough for me. I just zoom in if I need a better look at the > sound. That value of 128 samples is tunable by the way, just set that > low to be fast enough on low-end machines (like 486:es). > > Of course, everyone doesn't like the way my editor works. That's why > there are more than one soundfile editor around. :) > > /Magnus > ------------------------------------------------------------ > libsndfile-devel Mailing List > To unsubscribe: > > Begin forwarded message: > From: Juhana Sadeharju > Date: 5 August 2004 08:30:51 IST > To: libsndfile-devel@mega-nerd.com > Subject: [libsndfile-devel] Re: Overview file format > Reply-To: libsndfile-devel@mega-nerd.com > >> From: Magnus Hjorth >> >> My editor reads the first 128 samples belonging to each pixel > > In my experience the true min/max display is what is needed in > editors. The peaks of the audio are so important. > > But as you said, the overview format can be done in any case > if it only adds to libsndfile. > > Juhana > -- > http://music.columbia.edu/mailman/listinfo/linux-graphics-dev > for developers of open source graphics software > ------------------------------------------------------------ > libsndfile-devel Mailing List > To unsubscribe: > > Begin forwarded message: > From: Juhana Sadeharju > Date: 6 August 2004 11:12:30 IST > To: libsndfile-devel@mega-nerd.com > Subject: [libsndfile-devel] Re: Overview file format > Reply-To: libsndfile-devel@mega-nerd.com > >> From: Simon Burton >> >> It seems that apps that do need this (NLEs) will need much more >> trickery, >> tightly integrated with the editing process. > > But in the lowest level they have contiguous pieces of audio with > associated overview data on disk (rarely in memory). Audio file and > the associated overview file have the same time axis and duration. > > The edit decision list is on the top of both audio and overview data. > That is why there is no need to add EDL to the overview format itself. > >> Surely this is a hassle for GUI programmers ? They will have to create >> another thread to run the generate function. It's also tricky to do >> from, say, a python wrapper. Much easier (but maybe not for Erik) >> would >> be a >> >> int poll_generate_overview( ??? ) > > We should stay at the lowest level as I originally proposed. > > I have tried to come up a complete EDL library but these gets > complicated pretty soon. A complicated system forces other > developers to use the same complicated system -- or they just > choose to use their own system. That is not our intention. > > What I originally proposed would more likely end up to all editors. > > Juhana > -- > http://music.columbia.edu/mailman/listinfo/linux-graphics-dev > for developers of open source graphics software > ------------------------------------------------------------ > libsndfile-devel Mailing List > To unsubscribe: > > Begin forwarded message: > From: Erik de Castro Lopo > Date: 6 August 2004 11:24:16 IST > To: libsndfile-devel@mega-nerd.com > Subject: [libsndfile-devel] Re: Overview file format > Reply-To: libsndfile-devel@mega-nerd.com > > On Fri, 6 Aug 2004 13:12:30 +0300 > Juhana Sadeharju wrote: > >>> int poll_generate_overview( ??? ) >> >> We should stay at the lowest level as I originally proposed. > > I will be possible to use/generate overview files without > using poll_generate_overview() or whatever it may be called > in the end. > > Erik > -- > +-----------------------------------------------------------+ > Erik de Castro Lopo nospam@mega-nerd.com (Yes it's valid) > +-----------------------------------------------------------+ > "Linux is produced to be used, whereas the others are produced > to be sold" -- Bobby D. Bryant > ------------------------------------------------------------ > libsndfile-devel Mailing List > To unsubscribe: > >