gmane.comp.audio.audacity.devel

Re: Can this be committed ?

Steve the Fiddle — 2012-05-23T21:55:50

Terrific, thanks Richard, Nyquist-chains-3.patch builds for me too.
(good to see that my attempt was very close, just a couple of errors
in Nyquist.cpp, but the cigar goes to you :=)



The big advantage for many users is that we already have a library of
about 80 Nyquist plug-ins on the Audacity wiki, and many more on the
way from the forum so this greatly increases what can be done with
Chains. Not only can they be used for batch processing, but can be
used like "macro effects" on current projects.


I think that at least some of those issues have already been fixed,
but I'll log any that I spot while testing.

Steve


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Re: Can this be committed ?

Richard Ash — 2012-05-23T20:58:28

Not by far - one (actually irrelevant) hunk has been applied already
(shouldn't have been in this patch as it's debug cleanup), and one other
had it's context mangled by Martyn's cleanspeach work - easy enough to
sort.

Doesn't seem to be a problem building the attached for me.

It's not a feature I have ever used, or am likely to (given I write
shell script much better than lisp). So I haven't tested this patch, but
if I get a clear indication it is fit to be committed, I'm prepared to
do so, as it looks solid enough.

As far as I can see from the wiki, this worked but there may have been
some graphical issues within the Chains dialogue. If this is true, then
I'm inclined to commit and ask for a new bug on the graphical dialogue,
given the generally fairly rough state of chains, and this being a
useful enhancement.

Richard
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
audacity-devel mailing list
audacity-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[PATCH] FFmpeg on-demand based input

Michael Chinen — 2012-05-23T07:07:19

Hi,
Here is a set of patches that allows ffmpeg on demand importing,
updated for the new ffmpeg versions.
Since this is a sizable new feature I am attaching the patches.
I will commit as 10 modular commits (patches included), but for
testing convenience I am also attaching a combined patch that squashes
all 10.

I tested and debugged for a while. I don't think it's polished yet,
but since the user can switch it on and off, it is lower risk if I get
the OK to commit.

It enables EXPERIMENTAL_OD_FFMPEG, but the default functionality is
the non-OD import, which is selectable via the Library preference pane
in the ffmpeg section.
It also refactors the relevant code from the non OD method.
There are no large system/structural changes that would affect other
parts of the code.

I am not sure if seeking should be enabled or not since ffmpeg is not
always that accurate at seeking.
I expected to find more problems with it, but after these fixes in my
basic test cases it does the correct thing with my system ffmpeg. For
testing the patch, I will leave it in.
If we decide to disable it, this will simply become background linear
loading with no on-demand updates, which is still useful.
I tested on linux and mac on flv, wav, mp3 (vbr, cbr), m4a (aac), mpeg
video (audio track).

Michael
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
audacity-devel mailing list
audacity-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Re: 2.0.1?

Steve the Fiddle — 2012-05-23T03:15:37

Not being a developer myself I'm probably not eligible to vote on
whether to aim for a June release, but there have been quite a few
nice enhancements since 2.0 so from a user perspective it would be
nice to have another release fairly soon. If we go for a June release
then we should definitely be thinking and planning for it now.


Also I'm still intermittently (but quite frequently) losing keyboard
control. Just opening and closing preferences is usually enough to
restore keyboard control but it's still an annoying workaround.
Unfortunately I've still not been able to pin down what triggers the
loss of control, it seems quite random - one minute it is working then
the next minute not.


In case you've not guessed, I'm +1 for this feature :=)

Although the patch is no longer building against SVN head, it was
heavily tested toward the end of last year and worked well, so
hopefully it would not take too much work to get it back up and
running again.

Steve


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Re: Further problem, obvious in Normalize

Martyn Shaw — 2012-05-22T23:48:24


On 22/05/2012 23:22, Gale Andrews wrote:

Good, so I am leaving at it is for now.
TTFN
Martyn


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Re: Further problem, obvious in Normalize

Gale Andrews — 2012-05-22T22:22:35

| From Martyn Shaw <martynshaw99< at >gmail.com> 
| Sat, 19 May 2012 21:33:06 +0100
| Subject: [Audacity-devel] Further problem, obvious in Normalize

I too didn't find any issues after the fix. Thanks.



Yes, I see. I don't know what the answer is, unless we were to 
estimate remaining time based on a factor that processing takes 
3x (or whatever) as long as an analyze. Or unless we pushed 
dynamic text in front of "Remaining Time" to indicate the part 
that time referred to (assuming it was even possible).  

I assume users would tend to see the remaining time for the 
whole "Normalize..." (window title) process in the absence 
of other indication. 

Re: the messages, thanks for the two lines change, much better. 
There is still some inconsistency, though I don't think it's too bad. 
When normalizing a stereo pair with "independently" unchecked
we see:

1 Analysing first track <track name>
2 Analysing second track <track name>
3 Processing first track <track name>
4 Processing second track <track name>

With "independently" checked we see:

1 Analysing <track name> 
2 Processing stereo channels independently <track name>
3 Analysing <track name>
4 Processing stereo channels independently <track name>

So there is a kind of expectation step 2 could be the end of the 
"independent" Normalize, from a casual inspection. 

When doing "independent" normalize, is it still complex to append 
"first track" or "second track"? Or to go 1, 3, 2, 4? Or to go 
1, 3, 2, 4 when not "independent"?  



Gale  




------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Re: working round bug 152

Steve the Fiddle — 2012-05-22T21:31:59

I've been discussing bug 152 with Edgar Franke (edgar-rft).

We are in agreement that my original patch to nyquist/dspprims.lsp is incorrect.
We are also in agreement that the new patch is a much better fix.

The problem actually arises in the snd-biquad function in
/lib-src/libnyquist/nyquist/tran/biquadfilt.c
but patching at that point is *highly problematic*. (more information
about this in this forum post:
http://forum.audacityteam.org/viewtopic.php?p=180062#p180062 )

The only known conditions to cause snd-biquad to generate infinites
and NANs are when functions that use nyq:lowpass2 or nyq:highpass2
pass a frequency value that is out of range. The patch addresses these
cases directly by throwing an error for out of range frequency values
in nyq:lowpass2 and nyq:highpass2.

The functions that use nyq:lowpass2 and nyq:highpass2 are intended to
be called directly by user code, so I think it is totally appropriate
to tests for obviously wrong argument values, and that is what this
patch does.

+1 for committing this patch.

Steve


On 21 May 2012 22:34, Gale (Audacity Team) <gale< at >audacityteam.org> wrote:

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Re: Further problem, obvious in Normalize

Martyn Shaw — 2012-05-21T22:25:52

Great!  Thanks for testing Peter!  And sorry it took so long / so many 
iterations.

TTFN
Martyn

On 21/05/2012 12:13, Peter Sampson wrote:

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Re: working round bug 152

Gale (Audacity Team — 2012-05-21T21:34:38

Replying just to -devel to save cross-posts.  

I would suggest the patch is committed and Steve releases the unpatched
plug-in 
to Wiki after 2.0.1 (or a developer says the patch is incorrect or the wrong
way 
to go so Steve knows to release a patched plug-in).    

Here is a diff of the patch:
http://bugzilla.audacityteam.org/attachment.cgi?id=256&action=diff . 



Gale 

--
View this message in context: http://audacity.238276.n2.nabble.com/working-round-bug-152-tp7555241p7555246.html
Sent from the audacity-devel mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

2.0.1?

Gale (Audacity Team — 2012-05-21T21:13:28

If we would like a 2.0.1 mid to end June (so still roughly three months after
2.0.0)
we ought to start thinking about it.

Have we got enough "new things" in it? 

Support for VoiceOver on Mac (already committed) will be a big plus for VI
users,
though David has recently asked for more testing:
http://www.freelists.org/post/audacity4blind/Audacity-20-build-for-Mac,14 . 

The (limited) Effects shortcut functionality would surely be popular but is 
still Windows only, and removing an effect doesn't remove its shortcut,
which gets assigned to another plug-in.

What are the issues with implementing effects shortcuts on the other
platforms?  
As it is now, an embarrassing glitch can be found on Linux and Mac if you 
default the shortcuts:
http://audacity.238276.n2.nabble.com/Ctrl-R-AWOL-on-Linux-td7528376.html .

In sum, I'm not sure effects shortcuts are ready for release at the moment. 

If effects shortcuts are not released this time around, Nyquist Effects in
chains 
could be a nice "new thing for everyone" that as far as I know is fairly
well tested 
already:
http://audacity.238276.n2.nabble.com/Can-this-be-committed-td7551739.html .

I'm hoping not too much effort would be needed to get at least one of those 
two new features polished to releasability (and may be a couple of P2's 
vanquished -  http://tinyurl.com/cfc7hz5 ) by the end of June? 



Gale 


--
View this message in context: http://audacity.238276.n2.nabble.com/2-0-1-tp7555245.html
Sent from the audacity-devel mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Re: Patch for bug 50 – calculation of remaining space for 24-bit recording

Miroslav Matějů — 2012-05-21T19:13:53

Hello Michael,
Thanks for the review. The comment from AudioIO.cpp you quoted agrees
with what I have experienced - for 24bit samples, Audacity takes float
samples from PortAudio. However, it seems to convert those samples to
24bit format before saving to disk - I mean the Audacity project, not
a WAV export, and it's being done directly during recording, according
to my tests. This is the reason why I differentiated the original
mCaptureFormat variable into two variables: mCaptureFormat and
mSaveFormat with an intention to use each in the relevant context.

Best regards,
Miroslav

2012/5/19 Michael Chinen <mchinen< at >gmail.com>:

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

working round bug 152

Steve the Fiddle — 2012-05-21T13:42:31

I have a Nyquist plug-in that is tested and waiting to be uploaded to
the wiki. http://forum.audacityteam.org/viewtopic.php?f=42&t=65557
Unfortunately it is affected by bug 152.

I have written an update to the plug-in that works around bug 152.
I have also submitted a patch for bug 152 (tested on Linux, XP and Win
7 - should be platform independent)
http://bugzilla.audacityteam.org/show_bug.cgi?id=152

If the patch is applied then there is no need for the workaround in the plug-in.
Should I upload the plug-in that has the workaround, or wait for bug
152 to be closed?

The workaround in the plug-in replaces the functions nyq:highpass2 and
nyq:lowpass2 that are currently used in Audacity Nyquist with patched
local versions. If these functions are ever updated in Audacity then
the plug-in will still use the old patched version, so I think that it
would be better to upload the version without the workaround, but then
it will need to specify Audacity version 2.1 (or whatever version
fixes these two functions).

Is there a policy about this? Can anyone advise?

Steve

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Re: Further problem, obvious in Normalize

Peter Sampson — 2012-05-21T11:13:43

Hi Martyn,
 
testing on r11743 today shows that the problem appears
to be fixed ok.  Messages look good too.
 
Looks ready to go to me.
 
Peter.

Peter Sampson
Tel: +44 (0)1625 524 780
Mob: +44 (0)7732 278 299


________________________________
From: Peter Sampson <petersampson48< at >yahoo.com>
To: "audacity-devel< at >lists.sourceforge.net" <audacity-devel< at >lists.sourceforge.net> 
Sent: Friday, May 18, 2012 11:24 AM
Subject: Re: [Audacity-devel] Further problem, obvious in Normalize


Messages in r11740 look good to me too Martyn.
I like the fact that user are addvised when thy normailze
without DC removal - a good reminder.
 
But there is one *big* problem:
 
When you use the Normalize efffect with just DC removal 
selected and no Normalization, it not only makes the first 
pass to do the Dc Removal (with correct message) - it then 
goes on to tell you that it is "Normalizing <x> track ..."
 
And indeed it does apply normalization amplitude adjustment,
it looks as though it is using the value that is left greyed-out 
in the dB box.
 
I use Normalize a lot, immediately after capture from one of my
sound cards, without amplitude adjustment.  So this would be 
a big problem for me (and other users who employ a sensible
workflow).
 
Thanks,
Peter.
 
Peter.


Peter Sampson
Tel: +44 (0)1625 524 780
Mob: +44 (0)7732 278 299


________________________________
From: Gale (Audacity Team) <gale< at >audacityteam.org>
To: audacity-devel< at >lists.sourceforge.net 
Sent: Friday, May 18, 2012 12:53 AM
Subject: Re: [Audacity-devel] Further problem, obvious in Normalize

"Martyn Shaw-3" wrote:
Thanks! I tried it with some two hour tracks so I could hopefully follow the
messages.

It's nice to see the progress bar behave more consistently now. 

Something seems wrong. I have a saved project as a stereo pair, two tones,
the left at -10 dB, right at -1.9 dB. Split into L/R or not, if I select
about 20 
minutes and just remove offset (Normalize is greyed out at -2 dB, 
"independently" greyed out unchecked), I still see a "Normalizing" message. 
The selection in the left channel is deamplified by -2 dB to -12 dB and the 
right deamplified by - 2 dB to -3.9 dB. This seems easy to reproduce. 

If I remove offset and and normalize on a stereo pair, I see "Analyzing" 
then "Analyzing second track" but never "Analyzing first track". If that
is correct, should there not be "Analyzing first track" in that case? 

Personally I think it might be slightly preferable if "Processing stereo 
channels independently" wasn't a separate bottom line. I "think" that
would make a maximum two lines of messages, and whatever you were 
doing, the last line would be <action><track name>. So if "normalizing 
stereo channels independently", the last line would be "Normalizing stereo
channels independently: <track name>".

Generally, I would rather see one total estimate of remaining time even 
when removing offset as well as normalizing. On my two hour track after a 
few seconds of analysing I see only about 25 seconds remaining, so might
turn away for half a minute expecting it to be done when I look again, 
but instead see another four minutes still remaining.

As an aside, if you cancel the progress dialogue, it jumps down a little 
diagonally to bottom right when "Not Responding" appears in the window
title, but so do all the others I tried.



Gale 





--
View this message in context: http://audacity.238276.n2.nabble.com/Further-problem-obvious-in-Normalize-tp7518598p7555211.html
Sent from the audacity-devel mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
audacity-devel mailing list
audacity-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/audacity-devel



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
audacity-devel mailing list
audacity-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/audacity-devel------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
audacity-devel mailing list
audacity-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Re: Can this be committed ?

Steve the Fiddle — 2012-05-21T06:06:20

The patch appears to be dead.
It won't apply to the current svn code and when I try patching
manually I can't get it to build.

It seems such a shame to lose all of the work that has gone into
getting this feature so close for no return.
Is there really no interest at all?

Steve

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Re: Further problem, obvious in Normalize

Martyn Shaw — 2012-05-19T20:33:06

Hi Gale, and others

Thanks for the testing!

On 18/05/2012 00:53, Gale (Audacity Team) wrote:

Oops!  My bad.  Now fixed.  I never tested that case.


OK, I've added a conditional for that.


Ok, it's a matter of vertical space vs horizontal space.  I put it on 
2 lines instead of 3, see what you think.

I also changed the <action> of 'Normalizing' to 'Processing' as the 
actual  process is already on the first line, after Peter's comment.


I think that would be very difficult / impossible to do since during 
the first 'Analyze' phase there is no way of knowing how long the 
'Processing' phase could take.  I will strive for an improvement though.

HTH
Martyn


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Re: Patch for bug 50 – calculation of remaining space for 24-bit recording

Michael Chinen — 2012-05-18T22:12:12

Hi,

Sorry it's a bit late for review, but here:

On Sat, May 12, 2012 at 1:13 AM, Miroslav Matějů <melebius< at >gmail.com> wrote:

The comment suggests that we don't use 3 bytes, and we may use a full float.

Also see AudioIO.cpp in the recording callback:3542 :
                // We should never get here. Audacity's int24Sample
format
                // is different from PortAudio's sample format and so
we
                // make PortAudio return float samples when recording
in
                // 24-bit samples.
                wxASSERT(false);

So I think we need to treat 24 bit int recording the same as float
recording, meaning we shouldn't apply the patch.
I think you are thinking about the 24 bit wav that is exported, but
this is not related to the space available for recording.
Thanks,

Michael

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
audacity-devel mailing list
audacity-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Re: Further problem, obvious in Normalize

Steve the Fiddle — 2012-05-18T15:09:48

It's not normalizing, it's amplifying by the greyed out value.

Steve



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Re: Further problem, obvious in Normalize

Peter Sampson — 2012-05-18T10:24:22

Messages in r11740 look good to me too Martyn.
I like the fact that user are addvised when thy normailze
without DC removal - a good reminder.
 
But there is one *big* problem:
 
When you use the Normalize efffect with just DC removal 
selected and no Normalization, it not only makes the first 
pass to do the Dc Removal (with correct message) - it then 
goes on to tell you that it is "Normalizing <x> track ..."
 
And indeed it does apply normalization amplitude adjustment,
it looks as though it is using the value that is left greyed-out 
in the dB box.
 
I use Normalize a lot, immediately after capture from one of my
sound cards, without amplitude adjustment.  So this would be 
a big problem for me (and other users who employ a sensible
workflow).
 
Thanks,
Peter.
 
Peter.
 
 
Peter Sampson
Tel: +44 (0)1625 524 780
Mob: +44 (0)7732 278 299


________________________________
From: Gale (Audacity Team) <gale< at >audacityteam.org>
To: audacity-devel< at >lists.sourceforge.net 
Sent: Friday, May 18, 2012 12:53 AM
Subject: Re: [Audacity-devel] Further problem, obvious in Normalize

"Martyn Shaw-3" wrote:
Thanks! I tried it with some two hour tracks so I could hopefully follow the
messages.

It's nice to see the progress bar behave more consistently now. 

Something seems wrong. I have a saved project as a stereo pair, two tones,
the left at -10 dB, right at -1.9 dB. Split into L/R or not, if I select
about 20 
minutes and just remove offset (Normalize is greyed out at -2 dB, 
"independently" greyed out unchecked), I still see a "Normalizing" message. 
The selection in the left channel is deamplified by -2 dB to -12 dB and the 
right deamplified by - 2 dB to -3.9 dB. This seems easy to reproduce. 

If I remove offset and and normalize on a stereo pair, I see "Analyzing" 
then "Analyzing second track" but never "Analyzing first track". If that
is correct, should there not be "Analyzing first track" in that case? 

Personally I think it might be slightly preferable if "Processing stereo 
channels independently" wasn't a separate bottom line. I "think" that
would make a maximum two lines of messages, and whatever you were 
doing, the last line would be <action><track name>. So if "normalizing 
stereo channels independently", the last line would be "Normalizing stereo
channels independently: <track name>".

Generally, I would rather see one total estimate of remaining time even 
when removing offset as well as normalizing. On my two hour track after a 
few seconds of analysing I see only about 25 seconds remaining, so might
turn away for half a minute expecting it to be done when I look again, 
but instead see another four minutes still remaining.

As an aside, if you cancel the progress dialogue, it jumps down a little 
diagonally to bottom right when "Not Responding" appears in the window
title, but so do all the others I tried.



Gale 





--
View this message in context: http://audacity.238276.n2.nabble.com/Further-problem-obvious-in-Normalize-tp7518598p7555211.html
Sent from the audacity-devel mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
audacity-devel mailing list
audacity-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/audacity-devel------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
audacity-devel mailing list
audacity-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Re: Further problem, obvious in Normalize

Gale (Audacity Team — 2012-05-17T23:53:05

Thanks! I tried it with some two hour tracks so I could hopefully follow the
messages.

It's nice to see the progress bar behave more consistently now.

Something seems wrong. I have a saved project as a stereo pair, two tones,
the left at -10 dB, right at -1.9 dB. Split into L/R or not, if I select
about 20
minutes and just remove offset (Normalize is greyed out at -2 dB,
"independently" greyed out unchecked), I still see a "Normalizing" message.
The selection in the left channel is deamplified by -2 dB to -12 dB and the
right deamplified by - 2 dB to -3.9 dB. This seems easy to reproduce.

If I remove offset and and normalize on a stereo pair, I see "Analyzing"
then "Analyzing second track" but never "Analyzing first track". If that
is correct, should there not be "Analyzing first track" in that case?

Personally I think it might be slightly preferable if "Processing stereo
channels independently" wasn't a separate bottom line. I "think" that
would make a maximum two lines of messages, and whatever you were
doing, the last line would be <action><track name>. So if "normalizing
stereo channels independently", the last line would be "Normalizing stereo
channels independently: <track name>".

Generally, I would rather see one total estimate of remaining time even
when removing offset as well as normalizing. On my two hour track after a
few seconds of analysing I see only about 25 seconds remaining, so might
turn away for half a minute expecting it to be done when I look again,
but instead see another four minutes still remaining.

As an aside, if you cancel the progress dialogue, it jumps down a little
diagonally to bottom right when "Not Responding" appears in the window
title, but so do all the others I tried.

Gale

--
View this message in context: http://audacity.238276.n2.nabble.com/Further-problem-obvious-in-Normalize-tp7518598p7555211.html
Sent from the audacity-devel mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Re: Noise coring filter

Marco Diego Aurélio Mesquita — 2012-05-17T14:29:34

Isn't it possible to turn Noise Coring into an option of the current
noise removal effect? Like a checkbox that can be marked/unmarked?

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Re: Noise coring filter

Steve the Fiddle — 2012-05-17T13:01:18

To Jerome, I'm not a developer, but I'm pleased to see work on this
feature continuing, it was showing a lot of promise when I tested the
previous patch.

To the developers, could this feature be accommodated as an
experimental feature (assuming that the current patch works, which
I've not tested yet)? Noise coring is already included in the wiki
proposal for improving Noise Removal and I think that including it in
the svn code would help to move this feature along. From testing the
old patch, with certain (common) types of noise/audio it can produce
significantly better noise removal than the current effect.

Steve


On 17 May 2012 09:04, "Jérôme M. Berger" <jeberger< at >free.fr> wrote:

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/