Hi Romain, Thanks for this. I will test this at weekend.
One more question for the remaining 1% : qwavheaderdump supports fixing track length by parameter -f: qwavheaderdump -F '$filename' Filenames are generic by using reopen_when() with "|%SMHdmY|" syntax. I would like to start an external qwavheaderdump -F call at stop of each recording, but would need to pass the filename to this. Is there a way to use the right filename at on_stop() function? BR, Peter Am 04.08.2011 06:11, schrieb Romain Beauxis: > 2011/8/3 Peter Retep<[email protected]>: >> Hi Romain, > Hi! > >> Thanks for this fast answer! >> >> 1) >> Approach 1 should help in 99% cases and would fit to our usage, btu the >> length of the first file will not be correct using this. > I have just committed this. > >> But how do you thing about predicting file length by "next reopen_when() >> event time" - "now()" ? >> This prevents using an additional parameter and furthermore the length of >> the first written file will be okay. > This is insteresting. However, I dont know about adding a parameter > whose meaning would be mostly intended for one particular format.. We > actually moved to %foo encoders partly to get rid of those issues.. > > I also think that with some efforts, it is totally possible to emulate > this by using dynamic sources. > >> 2) >> Since we are recording from ALSA there is no metadata, which makes approach >> 2 not helpful to us. > Word. > >> 3) >> A more generic solution could happen after the last write to a WAV file: >> if you know frequency, bitrate, number of channels and size of file and size >> of header you could update the length field by >> length = (file_size - header_size ) / (2 channels * 16 bit * 44100 bit/sec) > The problem with this is that we may not always have the possibility > to rewind the stream. The output could be /dev/null or stdout and we > actually do care about the latter... > >> 1) and 3) could be combined: >> - at start of recording file length could be predicted by reopen_when() or >> by length parameter. >> - at end of recording file length can be quickly measured and updated if not >> matching. >> This combination could make LS robust for writing WAVs at most start/stop >> cases (except LS process killing). > I think we'll have to stick with 1) for the moment.. Please let me > know if the changes are helpful to you.. > > Romain > ------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 _______________________________________________ Savonet-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/savonet-users
