Hi Romain, 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. 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. 2) Since we are recording from ALSA there is no metadata, which makes approach 2 not helpful to us. 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) 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). BR, Peter Am 03.08.2011 07:06, schrieb Romain Beauxis: > 2011/8/2 Peter Retep<[email protected]>: >> Hi, > Hi Peter! > >> as mentioned at ON2 last year we have problems with post processing of WAV >> output. >> Anyway, now I have found time to see, what is wrong with this: >> It seems that length is not encoded in the right way. > I confirm the issue.. The problem is that the WAV header is written > first and, when writting on-the-fly, total duration may not be known > at the time the header is written.. > > I am not sure that we can do much about this to actually reflects the > exact length of exported data. However, I can think of at least two > workarounds: > * Add an optional length parameter to %wav encoder. If the duration > of the files you will encode if known in advance, you could set it to > this value > * Use the "duration" metadata if available. This would only work for > encoding of files and could be tricky if the resulting files contains > several songs.. > > I think the first one is the only reasonable option. Could it fit your needs? > >> If you use WAVs recrded with LS for postprocessing like cutting it and >> encode it with lame, >> lame (3.98.4) will still copy this length field, a lot of media players will >> show the wrong length then. >> >> I have used qwavheaderdump (from the quelcom package) to check wav. >> >> qwavheaderdump 2011-08-02-00_00_00.wav >> 2011-08-02-00_00_00.wav (635054156 bytes): >> riff: 'RIFF' >> riff length: -268435457 >> riff length field should be 635054148 >> wave: 'WAVE' >> fmt: 'fmt ' >> fmt length: 16 >> format: 1 >> channels: 2 >> sample rate: 44100 >> bytes/second: 176400 >> bytes/sample: 4 >> bits/sample: 16 >> data: 'data' >> data length: -268435493 >> data length field should be 635054112 >> >> As a workaround one can use following command to fix teh WAV header. >> qwavheaderdump -F file.wav >> >> my encode settings: >> >> output.file( >> %wav(stereo=true), >> "/mnt/archive/piradio/%Y-%m-%d/%Y-%m-%d-%H_%M_%S.wav", >> reopen_when={0m0s}, >> mksafe(radio) >> ) >> >> my (still old) liquidsoap version as used in the production system: >> >> Liquidsoap 1.0.0-beta+svn (trunk/liquidsoap@rev8193). >> Copyright (c) 2003-2010 Savonet team >> Liquidsoap is open-source software, released under GNU General Public >> License. >> See<http://savonet.sf.net> for more information. >> >> Please confirm and I will create a ticket for this. >> >> >> It's the same for a nearly current release: >> >> Liquidsoap 1.0.0-beta2+svn (@644dd3b27614:20110706:175811) >> Copyright (c) 2003-2011 Savonet team >> Liquidsoap is open-source software, released under GNU General Public >> License. >> See<http://savonet.sf.net> for more information. >> >> quick test: >> liquidsoap 'output.file( %wav(stereo=true), "./test_%M.wav", >> reopen_when={0s}, mksafe(noise()) )' >> >> BTW: When using 'reopen_when={0s}' LS will not create a separate file for >> each minute. > This is probably due to the fact that 0s is too tight and that the > test is run for instance at 1s. Although, I think the test is executed > at each frame which by default is 0.04s I think.. > > The solution, I believe, is to use a wider range, something like: { 0-59s } > In this case and in order to avoid several reload withing the same > minute, the reload_delay prevents any reopening for the given duration > in seconds after the first reopening.. > > Please, let us know if the above works for 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
