From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS6130 216.105.38.0/24 X-Spam-Status: No, score=-3.4 required=3.0 tests=AWL,BAYES_00, DKIM_ADSP_CUSTOM_MED,DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.1 Received: from lists.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id E5EB51F454 for ; Thu, 27 Sep 2018 06:25:28 +0000 (UTC) Received: from [127.0.0.1] (helo=sfs-ml-4.v29.lw.sourceforge.com) by sfs-ml-4.v29.lw.sourceforge.com with esmtp (Exim 4.90_1) (envelope-from ) id 1g5Pjn-0003sM-Cy; Thu, 27 Sep 2018 06:25:23 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-4.v29.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1g5Pjl-0003sF-TZ for sox-users@lists.sourceforge.net; Thu, 27 Sep 2018 06:25:21 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=Content-Type:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=KKNPxEV80bKv2fTKfGH+0ixF5w8Eeksn9v9LswwxPQA=; b=LRh+WDvejjvhRX2taeSKBzCAj lnLPapvktCF46YCe2zuy4umseNw2RowUA+W8Ye3Qd8Zp9mCjQ156DQWT5iWtmajF0t73tclpDPUcS CKE1y2fg/d0g4oxnh8XOGTSjczIYfpjD8QlWdzOBjHg8Ebj/HXAHxWk4kHuCi85mxw0rQ=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=Content-Type:To:Subject:Message-ID:Date:From:In-Reply-To:References: MIME-Version:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=KKNPxEV80bKv2fTKfGH+0ixF5w8Eeksn9v9LswwxPQA=; b=nIvN+woaBph/HsK5LNx4MMrHhB eTgrXSDcsxCaFkd+x370iewG5BMCuwyMORzXOJYSZ+wGpawOYCkpS66y3goAr70YTCqx4ydUdvpLG MPmYYFiUO6WuhF9v1en9mtXuafTcZLJnVJlE86U8mmEZjBo05WlicbfODoB62htTEdak=; Received: from mail-lj1-f170.google.com ([209.85.208.170]) by sfi-mx-3.v28.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.90_1) id 1g5Pjj-007UK4-Ts for sox-users@lists.sourceforge.net; Thu, 27 Sep 2018 06:25:21 +0000 Received: by mail-lj1-f170.google.com with SMTP id y71-v6so1244926lje.9 for ; Wed, 26 Sep 2018 23:25:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=KKNPxEV80bKv2fTKfGH+0ixF5w8Eeksn9v9LswwxPQA=; b=Ats7V8OAJxUZ/TGlK9ixUdWrBZGbw6nh3sY5HAR7xg2E8ULiZPu90Dse531V0w1oZb yz1FAd2VXFm4ORgYJ+Z0b0sDGI8BQir2ODS9xe/IKwVywN2HSgnwIzFHcjcWXEuYWsbU qb9aDG1iS5t8nNCv2Js28BZV2LIW6cA9cEZaSSoITopGH53q48PV85i/ci1ixZ/xpxhe o3788D1EvgCf4jYaEjn4eEyLVfojYgUdrgIPuW61lOrZXzLOamB7XgQwG+sh8lTI37xi runJIFxb8BJhQmY/r2YL3gauahynbBzYM5tk2ILss+L58hqzTkuctZK91UDd//6Z56DY 6TWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=KKNPxEV80bKv2fTKfGH+0ixF5w8Eeksn9v9LswwxPQA=; b=EjZp+O/4owWuoiGyFkd7u/qgNMyEzi9FpBveNhKAtgu96VPbVdvM5WkqzrPiHg7Obh d+ouGqZFK++jkkcYij4H+6SxN0RLk0q4DwKBbkqOmemdOYL0koMnINSCevZCa1nx0vQx xt4q0itWZQOsRQx6vbC+N02s9hR+ilRIf1zI4ytDE4S5/BpU4twaaovbqPC1yJXICp29 heWj7KzBv3yyWq0+jGHZ/g2lK0edJlu3wL236sJNrO4MpqpkJHa4tKDl2IW4lJkJjKNw 3bGDpfR07LvJgb3x18eTW24ghxjeV7JzQvyC80syXq/cURiJzCA+ScpB7U0SbYQzxe0v 8Lrg== X-Gm-Message-State: ABuFfogOX9Fm5gCaZ+OGh2y8E6aVCUlB9vRD3XazwhIFfwrec07m15re MQ+UZJ0UcVW1gSxeLgsNbb9exxWZMGjjn7I+sFnkhBL+ X-Google-Smtp-Source: ACcGV63n8gYqImGEjtzeO69HXh6c7udwuvpAYN8mTr9KDIliRje1bIS76hFwLL8v681G9VzZfukqOE4qLPmdicM1KLg= X-Received: by 2002:a2e:9e55:: with SMTP id g21-v6mr7097394ljk.116.1538029512705; Wed, 26 Sep 2018 23:25:12 -0700 (PDT) MIME-Version: 1.0 References: <20180925194254.GA13391@www.stare.cz> <20180926181651.GA77937@www.stare.cz> In-Reply-To: <20180926181651.GA77937@www.stare.cz> From: Mikko Olkkonen Date: Thu, 27 Sep 2018 09:24:59 +0300 Message-ID: To: sox-users@lists.sourceforge.net X-Headers-End: 1g5Pjj-007UK4-Ts Subject: Re: remove known sample from audio X-BeenThere: sox-users@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: sox-users@lists.sourceforge.net Content-Type: multipart/mixed; boundary="===============8254165394245651049==" Errors-To: sox-users-bounces@lists.sourceforge.net --===============8254165394245651049== Content-Type: multipart/alternative; boundary="000000000000c250640576d4669c" --000000000000c250640576d4669c Content-Type: text/plain; charset="UTF-8" Jan Stary wrote: >343 * 0.0115 = 3.9445, so was the drums about 4 meters from the bass mic? Basically yes. Delays after the mics can be assumed negligible and/or equal. I can do the spill removal by trying out various values and picking up with the one with maximal correlation. Or maybe I implement some script that does that fiddling, lets see. Anyway, my idea when posting this issue was that maybe there is some clever way to use sox where I could avoid that manual operation (or scripting) required to find delay and vol that deliver the maximum correlation. I believe that at least audio watermarking folks must have streamlined this procedure so that they can detect their watermarks even if their audio has been (slightly) tweaked. It beats me that the wikipedia spill article did not discuss this postprocessing approach. It was all about studio setup that minimizes the problem _during_ the recording. Mikk00 On Wed, Sep 26, 2018 at 9:17 PM Jan Stary wrote: > On Sep 26 16:49:31, molkko@gmail.com wrote: > > I have two mics > > https://www.piksu.com/eps/tmp/mic1.wav > > https://www.piksu.com/eps/tmp/mic2.wav > > and audible spill in both. > > Yeah, the bass is not very precise and a bit behind the tempo. > > > I want to remove the spill from both. > > That's something different from what you described in > the original mail, but I understand your problem now. > > > I am able to remove the spill in this > > specific case (with outstanding results) > > for example for mic1.wav with commands > > sox mic2.wav mic2id.wav pad 0.0115 0 vol -0.13 > > sox -m -v 1 mic1.wav -v 1 mic2id.wav mic1clean.wav stat > > i.e. by inverting the other mic and mixing that _at suitable_ point in > time > > and suitable power to the signal to be cleaned. > > Indeed, it is very good. (The -v 1 are imho not necessary.) > > > The problem is that finding those values ("point in time" 0.0115 > > and power/"volume" -0.13) is cumbersome. Basically, I am after a command > > to find one given signal embedded in another given signal. > > That is very expensive, computation-wise. To find the offset, > I would compute the correlation of the mic1.wav and mic2.wav signals > for every suspected delay (say, for 0 to 0.1, with a step of 0.01) > and take the one where the correlation is maximal. > > Then "remove" the properly-delayed mic1id.wav from mic2.wav as above, > again with various levels of vol, and pick the one for which the > resulting "clean" signal has the maximal correlation with > the original mic2.wav. > > This problem must be as old as DSP. > http://www.dspguide.com/ > > > Jan > > > > > > On Tue, Sep 25, 2018 at 11:10 PM Jan Stary wrote: > > > > > On Sep 25 12:26:36, molkko@gmail.com wrote: > > > > What is the best way to subtract a known sample from given audio i.e. > > > > extract/reconstruct the original.wav from final.wav when final.wav > has > > > been > > > > created with commands: > > > > > > > > sox knownsample.wav knownsample_delay_gain.wav pad 0 vol > > > > sox -m original.wav knownsample_delay_gain.wav final.wav > > > > > > First of all, by "sample", you mean "signal", > > > not some one sample value, right? > > > > > > > original.wav is not anymore available. knownsample.wav and final.wav > are > > > > available. > > > > > > Do you also have knownsample_delay_gain.wav ? > > > > > > > pad delay and the vol parameter are known _roughly_ (X =~10ms, > > > > Y=~0.1) > > > > > > So you want to reconstruct original.wav from the mix > > > AND one of the originals - that's quite different than reconstructing > > > from just the mix.wav (which I doubt would be possible). > > > > > > > PS1, I can reconstruct the original with the process below but this > > > method > > > > is very cumbersome: > > > > repeat { > > > > come up with some guessed X and Y > > > > sox knownsample.wav knownsample_delay_gain.wav pad 0 vol - // > is > > > > also inverted > > > > sox -m -v 1 original.wav -v 1 knownsample_delay_gain.wav final.wav > stat > > > > } until RMS amplitude reported by stat has reached local minimum > > > > > > You said you no longer have original.wav, but you are using it here. > > > So what's there to reconstruct? > > > > > > > PS2, The original problem is a two musical instruments recorded > > > > simultaneously in the same space. They have their own mics but the > other > > > > instrument is audible in each recording. I want to remove the "wrong > > > > instrument" from each recording and have clean audio for both > > > instruments. > > > > > > https://en.wikipedia.org/wiki/Spill_(audio) > > > This should be your starting paragraph, not PS2. > > > > > > So show us the files: the mix (final.wav) and > > > the non-delayed bleeding instrument (knownsample.wav). > > > Also, name them more plainly (guitar, trumpet, mix - or whatever). > > > > > > It will be much easier to help you then. > > > > > > > > > Jan > > > > > > > > > > > > _______________________________________________ > > > Sox-users mailing list > > > Sox-users@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/sox-users > > > > > > > > > -- > > Terveisin, Mikko > > +358-40 506 6146 > > > > _______________________________________________ > > Sox-users mailing list > > Sox-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/sox-users > > > > _______________________________________________ > Sox-users mailing list > Sox-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sox-users > --000000000000c250640576d4669c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Jan Stary <hans@stare.cz> wrote:
>343 * 0.0115 =3D 3.9= 445, so was the drums about 4 meters from the bass mic?
Basically yes. Delays after the mics can be assumed negligibl= e and/or equal. I can do the spill removal by trying out various values and= picking up with the one with maximal correlation. Or maybe I implement som= e script that does that fiddling, lets see. Anyway, my idea when posting th= is issue was that maybe there is some clever way to use sox where I could a= void that manual operation (or scripting) required to find delay and vol th= at deliver the maximum correlation. I believe that at least audio watermark= ing folks must have streamlined this procedure so that they can detect thei= r watermarks even if their audio has been (slightly) tweaked. It beats me t= hat the wikipedia spill article did not discuss this postprocessing approac= h. It was all about studio setup that minimizes the problem _during_ the re= cording.
Mikk00


On Wed, Sep 26, 2018 at 9:17 PM Jan Stary <= hans@stare.cz> wr= ote:
On Sep 26 16:49:31, molkko@gmail.com wrote:
> I have two mics
> https://www.piksu.com/eps/tmp/mic1.wav
> https://www.piksu.com/eps/tmp/mic2.wav
> and audible spill in both.

Yeah, the bass is not very precise and a bit behind the tempo.

> I want to remove the spill from both.

That's something different from what you described in
the original mail, but I understand your problem now.

> I am able to remove the spill in this
> specific case (with outstanding results)
> for example for mic1.wav with commands
> sox mic2.wav mic2id.wav pad 0.0115 0 vol -0.13
> sox -m -v 1 mic1.wav -v 1 mic2id.wav mic1clean.wav stat
> i.e. by inverting the other mic and mixing that _at suitable_ point in= time
> and suitable power to the signal to be cleaned.

Indeed, it is very good. (The -v 1 are imho not necessary.)

> The problem is that finding those values ("point in time" 0.= 0115
> and power/"volume" -0.13) is cumbersome. Basically, I am aft= er a command
> to find one given signal embedded in another given signal.

That is very expensive, computation-wise. To find the offset,
I would compute the correlation of the mic1.wav and mic2.wav signals
for every suspected delay (say, for 0 to 0.1, with a step of 0.01)
and take the one where the correlation is maximal.

Then "remove" the properly-delayed mic1id.wav from mic2.wav as ab= ove,
again with various levels of vol, and pick the one for which the
resulting "clean" signal has the maximal correlation with
the original mic2.wav.

This problem must be as old as DSP.
h= ttp://www.dspguide.com/


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Jan


>
> On Tue, Sep 25, 2018 at 11:10 PM Jan Stary <hans@stare.cz> wrote:
>
> > On Sep 25 12:26:36, molkko@gmail.com wrote:
> > > What is the best way to subtract a known sample from given a= udio i.e.
> > > extract/reconstruct the original.wav from final.wav when fin= al.wav has
> > been
> > > created with commands:
> > >
> > > sox knownsample.wav knownsample_delay_gain.wav pad <X>= 0 vol <Y>
> > > sox -m original.wav knownsample_delay_gain.wav final.wav
> >
> > First of all, by "sample", you mean "signal",=
> > not some one sample value, right?
> >
> > > original.wav is not anymore available. knownsample.wav and f= inal.wav are
> > > available.
> >
> > Do you also have knownsample_delay_gain.wav ?
> >
> > > pad delay and the vol parameter are known _roughly_ (X =3D~1= 0ms,
> > > Y=3D~0.1)
> >
> > So you want to reconstruct original.wav from the mix
> > AND one of the originals - that's quite different than recons= tructing
> > from just the mix.wav (which I doubt would be possible).
> >
> > > PS1, I can reconstruct the original with the process below b= ut this
> > method
> > > is very cumbersome:
> > > repeat {
> > > come up with some guessed X and Y
> > > sox knownsample.wav knownsample_delay_gain.wav pad <X>= 0 vol -<Y> // is
> > > also inverted
> > > sox -m -v 1 original.wav -v 1 knownsample_delay_gain.wav fin= al.wav stat
> > > } until RMS amplitude reported by stat has reached local min= imum
> >
> > You said you no longer have original.wav, but you are using it he= re.
> > So what's there to reconstruct?
> >
> > > PS2, The original problem is a two musical instruments recor= ded
> > > simultaneously in the same space. They have their own mics b= ut the other
> > > instrument is audible in each recording. I want to remove th= e "wrong
> > > instrument" from each recording and have clean audio fo= r both
> > instruments.
> >
> > https://en.wikipedia.org/wiki/Spill_(audio)=
> > This should be your starting paragraph, not PS2.
> >
> > So show us the files: the mix (final.wav) and
> > the non-delayed bleeding instrument (knownsample.wav).
> > Also, name them more plainly (guitar, trumpet, mix - or whatever)= .
> >
> > It will be much easier to help you then.
> >
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jan
> >
> >
> >
> > _______________________________________________
> > Sox-users mailing list
> > Sox-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/= listinfo/sox-users
> >
>
>
> --
> Terveisin, Mikko
> +358-40 506 6146


> _______________________________________________
> Sox-users mailing list
> S= ox-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listi= nfo/sox-users



_______________________________________________
Sox-users mailing list
Sox-us= ers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/s= ox-users
--000000000000c250640576d4669c-- --===============8254165394245651049== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============8254165394245651049== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sox-users mailing list Sox-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sox-users --===============8254165394245651049==--