Thread: Re: [Audacity-devel] Zoom Issue
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: <Mar...@ao...> - 2007-03-27 23:37:04
|
I've seen this here, can reproduce it, (think I) know what the problem is, but don't know how to fix it. To reproduce: Generate a tone 360s long (357.95s does it here, but maybe it depends on window size?). Zoom in with the '+' magnifier 17 times (or so) - has it jumped? Mine did. Try it again using Ctrl+1 17 times to zoom in - did it trigger an assertion in li 1330? Mine did (unicode debug). The value being calculated in TrackPanel::TimeToPosition is overflowing an int when mViewInfo->zoom is very large. Maybe it's overflowing elsewhere as well?? I tried changing TimeToPosition to 'long' but it didn't help, maybe I did it wrong. HTH Martyn PS definite bug, but does not explain Cliff-the-lurker's problem, I suspect. In a message dated 27/03/2007 23:25:28 GMT Daylight Time, cli...@ch... writes: Hello, I have seen this issue occasionally in 1.3.2 beta OSX intel version. I had recorded both sides of a vinyl album to one project (one stereo track) and was editing out the clicks. I used the magnifying glass mouse tool to zoom in on the area of interest (until the individual samples are seen) - marked the click and used the Repair effect. Then using the zoom out button (multiple rapid clicks) to get back to a "regular" view. On occasion, perhaps 2 times in 10, while zooming out the view would jump to the beginning of the project track. Hope this helps. Cliffl Lurker at Large On Mar 27, 2007, at 5:02 PM, Leland wrote: > > On 3/27/07 3:57 PM, "Richard Ash" <ri...@au...> wrote: > >> * The zoom issue Udo reported needs squashing - I haven't yet >> tried to >> replicate it, but I think long files are required to do so, as >> suggested. > > I've been trying to reproduce it on both OSX and Windows. I've > generated a > 4 hour Tone and I simply can't get it to happen. I've tried HEAD > and the > 1.3.2 version. > > Can you get it to happen? > > Leland > > |
From: Udo v. d. H. <ud...@xs...> - 2007-03-28 17:55:30
|
Mar...@ao... wrote: > I've seen this here, can reproduce it, (think I) know what the problem is, > but don't know how to fix it. > > To reproduce: > Generate a tone 360s long (357.95s does it here, but maybe it depends on > window size?). I have a dual screens setup (1280*1024 each) with Audacity set slightly wider than one screen. > Zoom in with the '+' magnifier 17 times (or so) - has it jumped? Mine did. > Try it again using Ctrl+1 17 times to zoom in - did it trigger an assertion > in li 1330? Mine did (unicode debug). How can I do that? > In a message dated 27/03/2007 23:25:28 GMT Daylight Time, > cli...@ch... writes: > "regular" view. On occasion, perhaps 2 times in 10, while zooming out > the view would jump to the beginning of the project track. Zooming OUT is something different from what i see when zooming in... (but still interesting to fix!) My method: Get the file (source is 48 Khz, stereo 16 bit audio) of about 1-2 hours. Load into Audacity. There it is converted to 32-bit values. I look at the file for spikes etc, I zoom in enough times and too often I see the beginning of the file instead of the part I want to see. I repeat once or twice and I get to see the correct part with the spike. Kind regards, Udo |
From: <Mar...@ao...> - 2007-03-29 00:04:00
|
Hi Markus Good try, I get this error message (but please read on...) TrackPanel.cpp ..\src\TrackPanel.cpp(1818) : error C2668: 'abs' : ambiguous call to overloaded function C:\Program Files\Microsoft Visual Studio 8\VC\include\math.h(539): could be 'long double abs(long double)' C:\Program Files\Microsoft Visual Studio 8\VC\include\math.h(491): or 'float abs(float)' C:\Program Files\Microsoft Visual Studio 8\VC\include\math.h(487): or 'double abs(double)' C:\Program Files\Microsoft Visual Studio 8\VC\include\math.h(485): or 'long abs(long)' C:\Program Files\Microsoft Visual Studio 8\VC\include\stdlib.h(415): or 'int abs(int)' while trying to match the argument list '(wxInt64)' I note that wxInt64 is a 'long long' that would appear to not have a version of 'abs' in VS8 (?). I locally bodged if(abs( SelStart-x) < minimumSizedSelection) to if((long)abs( long(SelStart-x)) < minimumSizedSelection) to get over the problem., and the code no longer asserts at this point. But I don't think this is a fix. Unfortunately the zoom problem still exists, almost exactly as I described it before. The assert has gone (obviously) but the jumping back to zero hasn't. As I said, this same overflow problem must be happening elsewhere in the code as well, I just don't know where. And I have looked. I have also noticed that the horizontal scroll bar jumps to full width when the track jumps to zero, if this is any clue. All I have for now, any ideas where to look? Martyn In a message dated 28/03/2007 20:01:28 GMT Daylight Time, me...@me... writes: Mar...@ao... schrieb: > The value being calculated in TrackPanel::TimeToPosition is overflowing an > int when mViewInfo->zoom is very large. Maybe it's overflowing elsewhere as > well?? > > I tried changing TimeToPosition to 'long' but it didn't help, maybe I did it > wrong. > I now commited a patch to HEAD which changes all int parameters of TimeToPosition() and PositionToTime() to wxInt64. Also, in all places where TimeToPosition() was used, wxInt64 is now used for calculations and coordinate storage. Casual testing showed no negative side effects. Can you check if the zoom behaviour is better now? Markus ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Audacity-devel mailing list Aud...@li... https://lists.sourceforge.net/lists/listinfo/audacity-devel |
From: <Mar...@ao...> - 2007-03-29 00:19:14
|
Udo I am rather ignorant with regards anything other than VS8 on Audacity. Are you compiling the code yourself? If so, compiling with Unicode and Debug set will probably give you the assert message (not that it's there any more!). With errors like this a generated tone will probably give the same error, and is reproducible by anybody. I try and find a minimum case where the bug appears (try halving the time period and see if it occurs, if so halve again, if not increase by half the last reduction etc). Try and narrow problems down - 'at 3307500 samples it crashes' type reports are much more useful than 'about 1-2 hours'. I hope this does not offend. Martyn In a message dated 28/03/2007 18:56:23 GMT Daylight Time, ud...@xs... writes: Mar...@ao... wrote: > I've seen this here, can reproduce it, (think I) know what the problem is, > but don't know how to fix it. > > To reproduce: > Generate a tone 360s long (357.95s does it here, but maybe it depends on > window size?). I have a dual screens setup (1280*1024 each) with Audacity set slightly wider than one screen. > Zoom in with the '+' magnifier 17 times (or so) - has it jumped? Mine did. > Try it again using Ctrl+1 17 times to zoom in - did it trigger an assertion > in li 1330? Mine did (unicode debug). How can I do that? > In a message dated 27/03/2007 23:25:28 GMT Daylight Time, > cli...@ch... writes: > "regular" view. On occasion, perhaps 2 times in 10, while zooming out > the view would jump to the beginning of the project track. Zooming OUT is something different from what i see when zooming in... (but still interesting to fix!) My method: Get the file (source is 48 Khz, stereo 16 bit audio) of about 1-2 hours. Load into Audacity. There it is converted to 32-bit values. I look at the file for spikes etc, I zoom in enough times and too often I see the beginning of the file instead of the part I want to see. I repeat once or twice and I get to see the correct part with the spike. Kind regards, Udo ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Audacity-devel mailing list Aud...@li... https://lists.sourceforge.net/lists/listinfo/audacity-devel |
From: Udo v. d. H. <ud...@xs...> - 2007-03-29 15:12:01
|
Mar...@ao... wrote: > I am rather ignorant with regards anything other than VS8 on Audacity. Are > you compiling the code yourself? I did in the past (to fix other issues or get features early). Current build is a Fedora build. I am on Linux. FC6. > If so, compiling with Unicode and Debug set > will probably give you the assert message (not that it's there any more!). I could give that a try. If that happens, what then? I can read the source to a certain degree, I can change stuff but I do not have enough overview to know what I am looking for or doing. > > - 'at 3307500 samples it crashes' type reports are much more useful than > 'about 1-2 hours'. I hope this does not offend. I mean to say that the files are that long. Current file is 2h04m41s+35 cdda frames. If I zoom in around the 2h04m mark I can easily reproduce the issue. Also near the beginning of the file or halfway it happens as far as I remember. Kind regards, Udo |
From: <Mar...@ao...> - 2007-03-30 01:29:07
|
Yippee! I finally found where the bug is (I think, 'proof' below), and (as suspected) it is an overflow of an int. The problem is with wxScrollBar; I don't know how to fix it, and need some ideas. Let's see if I found it though: The problem is with the horizontal scroll bar. In Project.cpp (about li 1003) we set mViewInfo.sbarTotal which subsequently gets used to set the range of a wxScrollBar, which is an int. >From what I can figure out, mViewInfo.sbarTotal is the total number of pixels it would take to display the waveform, at this zoom level, if they were available (ie you had a very very large monitor, if you zoom in). That is mViewInfo.total(s)*mViewInfo.zoom(px/s) = pixels. However as we zoom in this overflows, causing the problem. mViewInfo.zoom is limited to 6000000px/s, in AudacityProject::Zoom (that's about 136 pixels per sample at CD sampling rates, which seems adequate). The overflow level of an int (here) is 2147483647 and so this give a maximum mViewInfo.total as 2147483647/6000000s = 357.91s before we get a problem at maximum zoom, pretty close to the (experimental) 357.95s that I reported the minimum length the error would occur at a couple of days ago. mViewInfo.total is the length of the audio, in seconds; for you about 7481s (2h04m41s). Assuming you are working a CD sampling rate of 44100 samples/s you should see the error occurring when you zoom in beyond about 6.5s of visible audio. Can you confirm this? TTFN Martyn PS I tried limiting sbarTotal to the max int value but then we can't drag the scrollbar to the end of the waveform, so that's not a very good idea, although it stops the jumping. It would be better for us if wx supported long long for this parameter. In a message dated 29/03/2007 16:12:14 GMT Daylight Time, ud...@xs... writes: Mar...@ao... wrote: > I am rather ignorant with regards anything other than VS8 on Audacity. Are > you compiling the code yourself? I did in the past (to fix other issues or get features early). Current build is a Fedora build. I am on Linux. FC6. > If so, compiling with Unicode and Debug set > will probably give you the assert message (not that it's there any more!). I could give that a try. If that happens, what then? I can read the source to a certain degree, I can change stuff but I do not have enough overview to know what I am looking for or doing. > > - 'at 3307500 samples it crashes' type reports are much more useful than > 'about 1-2 hours'. I hope this does not offend. I mean to say that the files are that long. Current file is 2h04m41s+35 cdda frames. If I zoom in around the 2h04m mark I can easily reproduce the issue. Also near the beginning of the file or halfway it happens as far as I remember. Kind regards, Udo |
From: Markus M. <me...@me...> - 2007-03-30 09:49:46
|
Hi Martyn, Mar...@ao... schrieb: > I finally found where the bug is (I think, 'proof' below), and (as > suspected) it is an overflow of an int. The problem is with wxScrollBar; I don't know > how to fix it, and need some ideas. > Good catch! With this information I could reproduce the problem and (hopefully) fix it. I just added a variable scaling factor to the horizontal scrollbar handling logic. Udo, can you check if it works for you now? Markus |
From: Leland <aud...@ho...> - 2007-03-30 13:04:04
|
On 3/30/07 4:49 AM, "Markus Meyer" <me...@me...> wrote: > Hi Martyn, > > Mar...@ao... schrieb: >> I finally found where the bug is (I think, 'proof' below), and (as >> suspected) it is an overflow of an int. The problem is with wxScrollBar; I >> don't know >> how to fix it, and need some ideas. >> > Good catch! With this information I could reproduce the problem and > (hopefully) fix it. I just added a variable scaling factor to the > horizontal scrollbar handling logic. Udo, can you check if it works for > you now? > Heck, I still can't reproduce, even at 2560x1600. Oh well, no biggie. Leland |
From: JP <pen...@rf...> - 2007-03-30 14:50:07
|
test pls disregard ~~~~~~~~~~~~~~~~~~~~~~~~~~ John Penovich Radio Free Asia 2025 M Street, NW Ste 300 Washington DC 20036 (202) 587-2042 ~~~~~~~~~~~~~~~~~~~~~~~~~~ CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact network[at]rfa[dot]org Visit us at www.rfa.org or www.techweb.rfa.org |
From: Udo v. d. H. <ud...@xs...> - 2007-03-30 16:54:35
|
Mar...@ao... wrote: > Yippee! > > I finally found where the bug is (I think, 'proof' below), and (as > suspected) it is an overflow of an int. The problem is with wxScrollBar; I don't know > how to fix it, and need some ideas. Markus Meyer <me...@me...> wrote: > Good catch! With this information I could reproduce the problem and > (hopefully) fix it. I just added a variable scaling factor to the > horizontal scrollbar handling logic. Udo, can you check if it works for > you now? I just found a moment to get the latest code from cvs (1.3.3-beta, right?), configure (--with-portaudio=v19 --without-portmixer --with-libsndfile=local --enable-shared=no --without-libtwolamebuild) and build audacity. I just did some tests and so far no zoom issue any more! *Thanks a lot* you both! (and others of course) I need to do more testing but this looks very promising. BTW: What would be the differences between 1.3.3-beta I just built and the 1.3.2 I got from Fedora updates? Kind regards, Udo |
From: Markus M. <me...@me...> - 2007-03-30 16:57:03
|
Udo van den Heuvel schrieb: > BTW: What would be the differences between 1.3.3-beta I just built and > the 1.3.2 I got from Fedora updates? > Lots of bugfixing, otherwise it's about the same. Markus |
From: <Mar...@ao...> - 2007-03-31 00:10:26
|
Markus Seems to be OK here now. Nice one! Martyn In a message dated 30/03/2007 10:49:59 GMT Daylight Time, me...@me... writes: Hi Martyn, Mar...@ao... schrieb: > I finally found where the bug is (I think, 'proof' below), and (as > suspected) it is an overflow of an int. The problem is with wxScrollBar; I don't know > how to fix it, and need some ideas. > Good catch! With this information I could reproduce the problem and (hopefully) fix it. I just added a variable scaling factor to the horizontal scrollbar handling logic. Udo, can you check if it works for you now? Markus |
From: Markus M. <me...@me...> - 2007-03-28 19:00:29
|
Mar...@ao... schrieb: > The value being calculated in TrackPanel::TimeToPosition is overflowing an > int when mViewInfo->zoom is very large. Maybe it's overflowing elsewhere as > well?? > > I tried changing TimeToPosition to 'long' but it didn't help, maybe I did it > wrong. > I now commited a patch to HEAD which changes all int parameters of TimeToPosition() and PositionToTime() to wxInt64. Also, in all places where TimeToPosition() was used, wxInt64 is now used for calculations and coordinate storage. Casual testing showed no negative side effects. Can you check if the zoom behaviour is better now? Markus |