Hi everybody,
Is it possible to record 2 audio files with [writesf~] in a manner that the second starts "exactly after" the first one stops? In other words so that there will be a seamless (click-free) transisition when glueing the two together.
Peter Plessas and I have tried this with the attached patch, expecting to get either a perfect transition, _or_ to run late by exactly one block of audio (in our case 64 samples). But instead it seems that we run somewhere between 15 and 20 samples late (after glueing them together in CoolEdit and through visual inspection).
Any hints on what's going on behind the scenes would be appreciated.
best, flo.H
#N canvas 501 25 549 270 10; #X msg 65 48 start; #X msg 137 136 stop; #X obj 65 -10 t b b; #X obj 65 -44 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 432 -21 loadbang; #X msg 432 21 ; pd dsp 1; #X obj 12 129 osc~ 220; #X msg 207 114 start; #X obj 166 82 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X msg 292 149 stop; #X obj 107 181 writesf~; #X obj 204 181 writesf~; #X text 85 -47 1) open both files and start first recording; #X text 189 82 2) stop first and start second recording; #X text 335 150 3) stop second recording; #X msg 107 19 open test1.wav; #X msg 279 107 open test2.wav; #X connect 0 0 10 0; #X connect 1 0 10 0; #X connect 2 0 0 0; #X connect 2 1 15 0; #X connect 2 1 16 0; #X connect 3 0 2 0; #X connect 4 0 5 0; #X connect 6 0 10 0; #X connect 6 0 11 0; #X connect 7 0 11 0; #X connect 8 0 7 0; #X connect 8 0 1 0; #X connect 9 0 11 0; #X connect 15 0 10 0; #X connect 16 0 11 0;
Hallo, Florian Hollerweger hat gesagt: // Florian Hollerweger wrote:
Is it possible to record 2 audio files with [writesf~] in a manner that the second starts "exactly after" the first one stops? In other words so that there will be a seamless (click-free) transisition when glueing the two together.
You have to make sure to activate the next [writesf~] on a block boundary and also close the first [writsf~] in that same block. See the [pd blockbang~] subpatch in the attachement for an example how to do it.
Ciao
Frank Barknecht Do You RjDj.me? _ ______footils.org__
Dear Frank, List
thanks for that help! Yes indeed it works and i have been able of doing it with less objects and the help of bang~ as well. There is one thing i still don't get: I always thought pd would try to execute non-signal messages inbetween audio blocks. And for two messages this would be the same interval unless Pd had too many messages to calculate and defers them after the next audio block. But the writesf~ example shows that this is not necessarily the case.
Thanks again!
Peter
Frank Barknecht wrote:
Hallo, Florian Hollerweger hat gesagt: // Florian Hollerweger wrote:
Is it possible to record 2 audio files with [writesf~] in a manner that the second starts "exactly after" the first one stops? In other words so that there will be a seamless (click-free) transisition when glueing the two together.
You have to make sure to activate the next [writesf~] on a block boundary and also close the first [writsf~] in that same block. See the [pd blockbang~] subpatch in the attachement for an example how to do it.
Ciao
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Tue, 2009-01-06 at 13:43 +0100, Peter Plessas wrote:
Dear Frank, List
thanks for that help! Yes indeed it works and i have been able of doing it with less objects and the help of bang~ as well. There is one thing i still don't get: I always thought pd would try to execute non-signal messages inbetween audio blocks. And for two messages this would be the same interval unless Pd had too many messages to calculate and defers them after the next audio block. But the writesf~ example shows that this is not necessarily the case.
i am sorry for being too lazy to test myself, butwhat is the actual result of this? does [writesf~] start recording between block boundaries? or does it stop recording between boundaries? or is there another reason for being forced to use [bang~]?
i somehow assumed, that [writesf~] doesn't use scheduled messages...
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Hi all,
Roman Haefeli wrote:
On Tue, 2009-01-06 at 13:43 +0100, Peter Plessas wrote:
Dear Frank, List
thanks for that help! Yes indeed it works and i have been able of doing it with less objects and the help of bang~ as well. There is one thing i still don't get: I always thought pd would try to execute non-signal messages inbetween audio blocks. And for two messages this would be the same interval unless Pd had too many messages to calculate and defers them after the next audio block. But the writesf~ example shows that this is not necessarily the case.
i am sorry for being too lazy to test myself, butwhat is the actual result of this? does [writesf~] start recording between block boundaries? or does it stop recording between boundaries? or is there another reason for being forced to use [bang~]?
i somehow assumed, that [writesf~] doesn't use scheduled messages...
I always thought that Pd would execute messages in between audio blocks. So if i sent two messages (stop old file, start new file), i expected them to happen in a gap between two blocks, hence gapless recorded files possible. Franks demonstration shows that i have to explicitly time those messages according to a block~ (or equivalent) in order to get this behavior. Still all blurry to me, let's look on!
regards, PP
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Hallo, Peter Plessas hat gesagt: // Peter Plessas wrote:
i somehow assumed, that [writesf~] doesn't use scheduled messages...
I always thought that Pd would execute messages in between audio blocks.
So if i sent two messages (stop old file, start new file), i expected
them to happen in a gap between two blocks, hence gapless recorded files
possible. Franks demonstration shows that i have to explicitly time
those messages according to a block~ (or equivalent) in order to get
this behavior. Still all blurry to me, let's look on!
Acutally I found that my patch also works without explicit block timing: Just replace the [pd blockbang~] subpatch with [bang] and see for yourself. However it fails if you try to record less than one block.
Ciao
Frank Barknecht Do You RjDj.me? _ ______footils.org__
Hi!
Frank Barknecht wrote:
Hallo, Peter Plessas hat gesagt: // Peter Plessas wrote:
i somehow assumed, that [writesf~] doesn't use scheduled messages...
I always thought that Pd would execute messages in between audio blocks.
So if i sent two messages (stop old file, start new file), i expected
them to happen in a gap between two blocks, hence gapless recorded files
possible. Franks demonstration shows that i have to explicitly time
those messages according to a block~ (or equivalent) in order to get
this behavior. Still all blurry to me, let's look on!Acutally I found that my patch also works without explicit block timing: Just replace the [pd blockbang~] subpatch with [bang] and see for yourself. However it fails if you try to record less than one block.
Yes, that seems to work for me too! But, can you test it with stereo [writesf~ 2] files? I get clicks on those ones.
thanks for helping out!
regards, PP
Ciao
Dear Frank, list,
probably having found the culprit, it looks like recording two consecutive 24bit .wav files using the [open -bytes 3 foo.wav] message does introduce a small click at the gap. This behavior is independent of weather the bangs are timed to blocksize intervals explicitely. Can anyone else confirm that? I glued the two file together using sox, and audibly and visually find a small click at the boundary.
see attached modified version of Frank's original patch.
regards, Peter
Frank Barknecht wrote:
Hallo, Florian Hollerweger hat gesagt: // Florian Hollerweger wrote:
Is it possible to record 2 audio files with [writesf~] in a manner that the second starts "exactly after" the first one stops? In other words so that there will be a seamless (click-free) transisition when glueing the two together.
You have to make sure to activate the next [writesf~] on a block boundary and also close the first [writsf~] in that same block. See the [pd blockbang~] subpatch in the attachement for an example how to do it.
Ciao
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
#N canvas 80 0 1175 736 10; #X obj 175 468 tabsend~ $0-scope; #N canvas 0 0 450 300 (subpatch) 0; #X array $0-scope 64 float 2; #X coords 0 1 63 -1 200 140 1; #X restore 158 554 graph; #X obj 844 584 soundfiler; #X obj 844 533 list append $0; #X obj 857 511 hradio 15 1 0 2 empty empty empty 0 -8 0 10 -262144 -1 -1 0; #X floatatom 844 612 5 0 0 0 - - -; #X obj 428 423 writesf~; #X obj 669 415 writesf~; #X obj 159 509 throw~ $0-out; #X obj 477 363 catch~ $0-out; #X msg 428 188 start; #X msg 478 228 stop; #X msg 669 290 start; #X msg 742 338 stop; #X obj 428 137 t b b; #X obj 669 252 t b b; #X obj 643 256 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 715 253 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 406 139 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 472 140 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X msg 844 557 read -resize /tmp/$1.wav $2-file$1; #X msg 844 490 0 , 1; #X msg 428 110 record; #N canvas 0 0 463 281 blockbang~ 0; #X obj 148 103 bang~; #X obj 243 80 inlet; #X obj 243 103 b; #N canvas 231 224 450 300 once-closed 0; #X obj 68 68 inlet; #X obj 119 67 inlet; #X msg 119 90 1; #X msg 151 91 0; #X obj 68 144 t a b; #X obj 68 182 outlet; #X obj 68 114 spigot 0; #X connect 0 0 6 0; #X connect 1 0 2 0; #X connect 2 0 6 1; #X connect 3 0 6 1; #X connect 4 0 5 0; #X connect 4 1 3 0; #X connect 6 0 4 0; #X restore 148 128 pd once-closed; #X obj 148 154 outlet; #X text 136 51 bang on block boundaries; #X connect 0 0 3 0; #X connect 1 0 2 0; #X connect 2 0 3 1; #X connect 3 0 4 0; #X restore 742 311 pd blockbang~; #N canvas 0 0 463 281 blockbang~ 0; #X obj 148 103 bang~; #X obj 243 80 inlet; #X obj 243 103 b; #N canvas 231 224 450 300 once-closed 0; #X obj 68 68 inlet; #X obj 119 67 inlet; #X msg 119 90 1; #X msg 151 91 0; #X obj 68 144 t a b; #X obj 68 182 outlet; #X obj 68 114 spigot 0; #X connect 0 0 6 0; #X connect 1 0 2 0; #X connect 2 0 6 1; #X connect 3 0 6 1; #X connect 4 0 5 0; #X connect 4 1 3 0; #X connect 6 0 4 0; #X restore 148 128 pd once-closed; #X obj 148 154 outlet; #X text 136 51 bang on block boundaries; #X connect 0 0 3 0; #X connect 1 0 2 0; #X connect 2 0 3 1; #X connect 3 0 4 0; #X restore 478 205 pd blockbang~; #N canvas 0 0 533 468 open-files 0; #X obj 104 239 hradio 15 1 0 2 empty empty empty 0 -8 0 10 -262144 -1 -1 0; #X obj 314 240 hradio 15 1 0 2 empty empty empty 0 -8 0 10 -262144 -1 -1 1; #X msg 104 214 0; #X msg 314 217 1; #X obj 162 92 t b b; #X obj 104 311 outlet; #X obj 314 314 outlet; #X obj 162 67 inlet; #X msg 104 274 open -bytes 3 /tmp/$1.wav; #X msg 314 275 open -bytes 3 /tmp/$1.wav; #X connect 0 0 8 0; #X connect 1 0 9 0; #X connect 2 0 0 0; #X connect 3 0 1 0; #X connect 4 0 2 0; #X connect 4 1 3 0; #X connect 7 0 4 0; #X connect 8 0 5 0; #X connect 9 0 6 0; #X restore 281 135 pd open-files; #N canvas 0 0 450 300 (subpatch) 0; #X array $0-file0 128 float 2; #X coords 0 1 128 -1 200 140 1; #X restore 425 485 graph; #N canvas 0 0 450 300 (subpatch) 0; #X array $0-file1 128 float 2; #X coords 0 1 128 -1 200 140 1; #X restore 625 485 graph; #X text 578 207 start recording on block boundaries; #X text 314 81 first press prepare , then record; #X obj 844 466 b; #X msg 844 443 open files into tables; #X msg 281 113 prepare recording; #X floatatom 648 74 5 0 0 0 ms_to_record - -; #X obj 742 289 delay 5; #X obj 478 184 delay 5; #X floatatom 840 186 5 0 0 0 - - -; #X obj 840 150 * 1000; #X obj 840 120 t b a; #X obj 840 99 * 1000; #X floatatom 840 73 5 0 0 0 blocks_to_record - -; #X obj 729 120 r $0-blockdurs; #X msg 799 44 1.39; #X msg 840 43 2; #X msg 875 44 2.1; #X text 696 73 or:; #X text 739 362 this blockbang~ is not that necessary here , it's just for looks - to have both arrays the same size.; #X obj 160 435 *~ 1; #X obj 160 404 osc~ 330; #X connect 2 0 5 0; #X connect 3 0 20 0; #X connect 4 0 3 0; #X connect 9 0 6 0; #X connect 9 0 7 0; #X connect 10 0 6 0; #X connect 11 0 6 0; #X connect 12 0 7 0; #X connect 13 0 7 0; #X connect 14 0 10 0; #X connect 14 0 18 0; #X connect 14 1 19 0; #X connect 14 1 35 0; #X connect 15 0 12 0; #X connect 15 0 16 0; #X connect 15 1 17 0; #X connect 15 1 34 0; #X connect 20 0 2 0; #X connect 21 0 3 0; #X connect 22 0 14 0; #X connect 23 0 13 0; #X connect 24 0 11 0; #X connect 24 0 15 0; #X connect 25 0 6 0; #X connect 25 1 7 0; #X connect 30 0 21 0; #X connect 31 0 30 0; #X connect 32 0 25 0; #X connect 33 0 34 1; #X connect 33 0 35 1; #X connect 34 0 23 0; #X connect 35 0 24 0; #X connect 37 0 36 0; #X connect 37 0 34 1; #X connect 37 0 35 1; #X connect 38 0 37 0; #X connect 38 1 37 1; #X connect 39 0 38 0; #X connect 40 0 39 0; #X connect 41 0 37 0; #X connect 42 0 40 0; #X connect 43 0 40 0; #X connect 44 0 40 0; #X connect 47 0 0 0; #X connect 47 0 8 0; #X connect 48 0 47 0;
-
Florian Hollerweger -
Frank Barknecht -
Peter Plessas -
Roman Haefeli