Thread: [Audacity-devel] Checklist - Windows build
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: James C. <cr...@in...> - 2007-09-21 20:40:13
|
From the checklist: > * [MJS] Audible click every million samples (24 seconds at 44 100 > Hz) with EQ Effect. If not fixed (or reverted to leave the earlier > "ringing" problem), must be stated in Release Notes. I would like a fix, but we can release-note this one if we have to. That could be done without more programming. > * Tweak all wording of built-in 'innertext:' help in file > HelpText.cpp... Wording. Does not involve more programming. > * [RA] Update the Unix manual page to distinguish between 1.3 and > 1.2. In particular, remove reference to 1.3 importing multiple files > from command line into the same Project, unless fixed (See Aim to for > details). Documentation. Does not involve more programming. > * Remove latency correction from Preferences until fixed so that > negative correction is applied and positive correction does not > delete the first part of the audio (see Priority Aim to). We could remove latency correction altogether from preferences. Quick and easy to do. However, I'd rather have latency correction - which may remove the first 100ms or so of recorded sound - than not have it at all. Anyone who uses the feature more than once is going to get the hang of how to use it. If they don't like it, don't enable it. If other people agree that having this version is better than taking it out, then we're ready as is. If not, then we take it out. FWIW my preference is we reinstate being able to shift before zero, but that's certainly not an essential. > * Fix: Jorge's Mis-selection of sample rate as 'default' when card > can't support file's rate. .... Correct me if I'm wrong, but this isn't a regression is it? In that case we've lived with it before, and we can continue to do so. I vote we demote this to a priority aim-to - i.e. it probably won't get done now. > Envelopes: some uncertainty about whether we're good to go. Basically > it needs someone (not Martin) to give it a run through. If the tests prove OK, could be that no more programming needed here either. Not yet in list: > [MM] "Play other tracks while recording new one" often crashes if one does > not make a selection. It's a crash, so either we fix it or we disable play-other-tracks while recording new one. Markus to say which. > Concern about whether the lost-audio-when-recording bug is present > on Windows too (report by Damian Minkov). What's seems clear is that Audacity is not reporting under runs on any version, as that seems to be the problem on Linux/Mac. Monty stated a while back that he does not use Audacity for recording because it has never been reliable for that. If this is a long standing bug which we have not made worse with 1.3.4, then we should go ahead with 1.3.4, and start investigating code for reporting under runs as a separate subsequent activity. If we've made it worse with 1.3.4, then it's a show stopper, and becomes the number one essential. We need to wait on Damian's report. ====== Summary: Seems to me to be saying that, for windows build, as far as the wiki checklist is concerned, we could be in a position where additional programming work is optional. If that is the case, can we discuss on this list what else we need to do besides programming before we are ready to release 1.3.4? My view is we don't need all the translation and we don't need all the manual. I see the key things as: - Are there items which are incorrectly classified on the checklist or missing altogether that should be in the essentials? Alexandre posted a number of issues recently, but I don't think any of those were flagged as essentials. For completeness we should get the relevant ones on to the aim-to list(s), late though these additions are. - Are we planning to change the installer to also install help in html format? If so, we need that to be tested with the 1.3.4. release, so we do need at least a draft *html* version of the manual. My view is that for 1.3.4 we can have 'to-be-written' sections in the manual, and work on getting them up to date on the wiki whilst the beta is out in test. - We will need a preliminary period of test by us of 1.3.4 before we put it out to beta testers. I would suggest max one week. - We need to write release notes. Release notes should be written on the wiki so that we can all contribute / update. As we are planning to do a recruitment drive, we should look at saying something about that in the release notes too. Priority aim-tos should probably be mentioned in the release notes as 'issues'. Could be that 1.3.4 will go out without Linux and Mac versions. Comments, clarifications and corrections please. --James. |
From: JP <pen...@rf...> - 2007-09-21 21:16:02
|
> -----Original Message----- > From: aud...@li... > [mailto:aud...@li...] On > Behalf Of James Crook > Sent: Friday, September 21, 2007 4:42 PM > To: Audaciy Devel > Subject: [Audacity-devel] Checklist - Windows build *snip* > > * Remove latency correction from Preferences until fixed so that > > negative correction is applied and positive correction does > not delete > > the first part of the audio (see Priority Aim to). > > We could remove latency correction altogether from > preferences. Quick and easy to do. However, I'd rather have > latency correction - which may remove the first 100ms or so > of recorded sound - than not have it at all. Anyone who uses > the feature more than once is going to get the hang of how to > use it. If they don't like it, don't enable it. > > If other people agree that having this version is better than > taking it out, then we're ready as is. If not, then we take > it out. FWIW my preference is we reinstate being able to > shift before zero, but that's certainly not an essential. If by your preference you mean that no audio will be deleted then I agree. If you mean that audio before zero is deleted then I strongly disagree. *snip* > > Envelopes: some uncertainty about whether we're good to go. Basically > > it needs someone (not Martin) to give it a run through. > If the tests prove OK, could be that no more programming needed here either. There is still some minor hinkyness here. When joining a clip from another track to a track that has a volume envelope, the newly joined clip will take on the amplitude of the first clip's last envelope point, rather than keep it's own envelope info. Furthermore, once joined you can't add and manipulate envelope points after the joint unless you save an re-open the project. *snip* > > [MM] "Play other tracks while recording new one" often > > crashes if one does not make a selection. > > It's a crash, so either we fix it or we disable > play-other-tracks while recording new one. Markus to say which. I have also seen and reported a bug where append record will crash when "Play other tracks while recording new one" is enabled and you are working in a project with multiple sample rates. Martyn made some headway on it but I haven't been able to figure it out. > Comments, clarifications and corrections please. > > > --James. > Thanks James and everyone jp ~~~~~~~~~~~~~~~~~~~~~~~~~~ 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: James C. <cr...@in...> - 2007-09-22 10:14:23
|
>JP wrote: >>James wrote: >>>Checklist :-) wrote: >>> * Remove latency correction from Preferences until fixed so that >>> negative correction is applied and positive correction does >>> not delete the first part of the audio (see Priority Aim to). >> We could remove latency correction altogether from >> preferences. Quick and easy to do. However, I'd rather have >> latency correction - which may remove the first 100ms or so >> of recorded sound - than not have it at all. Anyone who uses >> the feature more than once is going to get the hang of how to >> use it. If they don't like it, don't enable it. >> If other people agree that having this version is better than >> taking it out, then we're ready as is. If not, then we take >> it out. FWIW my preference is we reinstate being able to >> shift before zero, but that's certainly not an essential. > If by your preference you mean that no audio will be deleted > then I agree. If you mean that audio before zero is deleted > then I strongly disagree. My preference is shifting before zero with no audio deleted. I think it acceptable to run with the current version, and better than removing latency correction altogether. If as a group we don't agree that current version is acceptable, then we remove latency correction option altogether. At least that's what the checklist says. If we don't agree on that, then the wording of the checklist item needs modifying. >>> Envelopes: some uncertainty about whether we're good to go. Basically >>> it needs someone (not Martin) to give it a run through. > There is still some minor hinkyness here. When joining a clip > from another track to a track that has a volume envelope, the > newly joined clip will take on the amplitude of the first clip's > last envelope point, rather than keep it's own envelope info. Bad, but not a release blocker. > Furthermore, once joined you can't add and manipulate envelope > points after the joint unless you save an re-open the project. Unacceptable. We must fix this. If it's me doing it it will probably be a week before I even look at it, given other commitments. >>> [MM] "Play other tracks while recording new one" often >>> crashes if one does not make a selection. >> It's a crash, so either we fix it or we disable >> play-other-tracks while recording new one. Markus to say which. > I have also seen and reported a bug where append record will > crash when "Play other tracks while recording new one" is > enabled and you are working in a project with multiple sample > rates. Martyn made some headway on it but I haven't been able > to figure it out. OK. We need that in the checklist too. Great feedback. Thanks. --James. |
From: Martyn S. <mar...@go...> - 2007-09-23 15:01:09
|
James Crook wrote: ... >>>> Envelopes: some uncertainty about whether we're good to go. Basically >>>> it needs someone (not Martin) to give it a run through. > >> There is still some minor hinkyness here. When joining a clip >> from another track to a track that has a volume envelope, the >> newly joined clip will take on the amplitude of the first clip's >> last envelope point, rather than keep it's own envelope info. > > Bad, but not a release blocker. > >> Furthermore, once joined you can't add and manipulate envelope >> points after the joint unless you save an re-open the project. > > Unacceptable. We must fix this. If it's me doing it it will probably > be a week before I even look at it, given other commitments. I think I've just fixed both these problems in CVS. Martyn |
From: James C. <cr...@in...> - 2007-09-23 21:15:56
|
> Martyn Shaw wrote: >> JP wrote: >> ...newly joined clip will take on the amplitude of the first clip's >> last envelope point... once joined you can't add and manipulate >> envelope points after the joint unless you save and re-open the >> project. > I think I've just fixed both these problems in CVS. Martyn Confirmed. Thanks. I've updated the wiki accordingly. --James. |
From: Gale A. <ga...@au...> - 2007-09-21 22:56:08
|
| From James Crook <cr...@in...> | Fri, 21 Sep 2007 21:42:07 +0100 | Subject: [Audacity-devel] Checklist - Windows build | >not yet added: | >[MM] "Play other tracks while recording new one" often crashes if | > one does not make a selection. | It's a crash, so either we fix it or we disable play-other-tracks while | recording new one. Markus to say which. I have now added to the list - hopefully it will be a short-lived addition. Having said that we could not seriously release 1.4.0 with "play other tracks while recording" disabled. To do so in 1.3.4 is OK (just about). | > * Remove latency correction from Preferences until fixed so that | > negative correction is applied and positive correction does not | > delete the first part of the audio (see Priority Aim to). | We could remove latency correction altogether from preferences. Quick | and easy to do. However, I'd rather have latency correction - which may | remove the first 100ms or so of recorded sound - than not have it at | all. Anyone who uses the feature more than once is going to get the | hang of how to use it. If they don't like it, don't enable it. Latency correction in the Preferences (as we now have it, with positive values) will shift back the audio by the amount the user states. If he enters 1000 ms for whatever reason, that's what he'll get and very likely some real audio that should have been part of the recording will be lost, unless shifting behind zero is reinstated. If reinstated, then the user will see the white arrows indicating audio is behind zero and may time shift the audio back. Unless Markus says it's impossible, I don't see why Audacity could not align the start of such a behind zero recording with zero itself (this change could be made post 1.3.4 if needs be). | If other people agree that having this version is better than taking it | out, then we're ready as is. If not, then we take it out. | FWIW my preference is we reinstate being able to shift before zero, | but that's certainly not an essential. IMHO what we have now for latency correction is better than not having it only if shifting behind zero is reinstated, so that the whole of the recorded audio can be preserved. We already know that we can again play from the zero point audio that's timeshifted behind zero, so that is one objection less. | > * Fix: Jorge's Mis-selection of sample rate as 'default' when card | > can't support file's rate. .... | | Correct me if I'm wrong, but this isn't a regression is it? In that | case we've lived with it before, and we can continue to do so. I vote | we demote this to a priority aim-to - i.e. it probably won't get done now. It depends what OS we are looking at. On Windows which we are discussing here, the 1.3.3 behaviour is identical to that in 1.3.2 (file at unsupported , rate is imported at Default rate), although no one other than me has verified that AFIK. Jorge's apparent behaviour in 1.3.3 that he originally reported * is * a change on 1.3.2 i.e. as I understand it, he is always getting his Project Rate set to the rate of the imported file, irrespective of the imported file's rate. As discussed, this behaviour is preferred for 1.4.0 on all platforms, presumably as an essential, with a Preference to always force Project Rate to Default Rate to be added post 1.4.0 (currently "not aiming") | > Envelopes: some uncertainty about whether we're good to go. Basically | > it needs someone (not Martin) to give it a run through. I am still aiming to have a go (as I am at the innertext). As I am envelope illiterate, it might even be a good idea? | ... can we discuss on this list what else we need to do | besides programming before we are ready to release 1.3.4? My | view is we don't need all the translation and we don't need all the | manual. Absolutely so, and we can get experience with the Windows version this way, but without people able to work on Mac and test things like envelopes on that platform, we're stuck there? | - Are there items which are incorrectly classified on the checklist or | missing altogether that should be in the essentials? Alexandre posted a | number of issues recently, but I don't think any of those were flagged | as essentials. For completeness we should get the relevant ones on to | the aim-to list(s), late though these additions are. Yes- I have still got some of my very old notes to go through, though I did add a few "aim to's" yesterday as you saw. James, 1) is it easy to work in a Preference, shift-click on "Solo" (or whatever) to your ideas on Mute/Solo, so that users have some way to retain multiple solo buttons whilst keeping all your other ideas - including making mute and solo mutually exclusive (a track can't be both muted and solo)? Bjoern had a concern that we should not unmute when soloing but he has not yet specified where your ideas would not work for him. Presumably everyone else is in favour? 2) minor, but are you able to advise further on Truncate Audio, as IMHO what we have now is way inferior to what we had before. If not everyone can hear the artefacts with low thresholds should not the user decide whether to hear them or not? Simply disallow zero as an input value and note it in the dialogue if the original major destruction of the audio with a zero parameter set can't be fixed? Gale Outbound message virus free. Tested on: 9/21/2007 11:56:05 PM |
From: James C. <cr...@in...> - 2007-09-22 11:19:57
|
Gale Andrews wrote: > Latency correction in the Preferences (as we now have it, with positive values) > will shift back the audio by the amount the user states. If he enters 1000 ms > for whatever reason, that's what he'll get and very likely some real audio that > should have been part of the recording will be lost, unless shifting behind > zero is reinstated. If reinstated, then the user will see the white arrows > indicating audio is behind zero and may time shift the audio back. Unless > Markus says it's impossible, I don't see why Audacity could not align the start > of such a behind zero recording with zero itself (this change could be made > post 1.3.4 if needs be). Moving the newly recorded audio so it starts before zero is better than moving everything else! So I would not be in favour of planning to 'move everything else' automatically. > | > * Fix: Jorge's Mis-selection of sample rate as 'default' when card > | > can't support file's rate. .... > | > | Correct me if I'm wrong, but this isn't a regression is it? In that > | case we've lived with it before, and we can continue to do so. I vote > | we demote this to a priority aim-to - i.e. it probably won't get done now. > It depends what OS we are looking at. On Windows which we are discussing > here, the 1.3.3 behaviour is identical to that in 1.3.2 (file at unsupported , > rate is imported at Default rate), although no one other than me has verified > that AFIK. Jorge's apparent behaviour in 1.3.3 that he originally reported * is * > a change on 1.3.2 i.e. as I understand it, he is always getting his Project Rate > set to the rate of the imported file, irrespective of the imported file's rate. > As discussed, this behaviour is preferred for 1.4.0 on all platforms, presumably > as an essential, with a Preference to always force Project Rate to Default Rate > to be added post 1.4.0 (currently "not aiming") Here I'm more concerned about a regression relative to 1.2.6. That would make it a roadblock to release. It's sounds like we should demote this to an aim to. > | ... can we discuss on this list what else we need to do > | besides programming before we are ready to release 1.3.4? My > | view is we don't need all the translation and we don't need all the > | manual. > Absolutely so, and we can get experience with the Windows version > this way, but without people able to work on Mac and test things > like envelopes on that platform, we're stuck there? It's possible releasing 1.3.4 windows-only and pointing out we need more developers will bring us some more linux/Mac developers. One can hope. > | - Are there items which are incorrectly classified on the checklist or > | missing altogether that should be in the essentials? Alexandre posted a > | number of issues recently, but I don't think any of those were flagged > | as essentials. For completeness we should get the relevant ones on to > | the aim-to list(s), late though these additions are. > Yes- I have still got some of my very old notes to go through, though I did > add a few "aim to's" yesterday as you saw. We really need any essentials added into the list! Having lots of problems and not knowing what they are is a lot worse than having them clearly identified. > James, > 1) is it easy to work in a Preference, shift-click on "Solo" (or whatever) > to your ideas on Mute/Solo, so that users have some way to retain multiple > solo buttons whilst keeping all your other ideas - including making mute and > solo mutually exclusive (a track can't be both muted and solo)? Bjoern > had a concern that we should not unmute when soloing but he has not yet > specified where your ideas would not work for him. Presumably everyone > else is in favour? <not-a-release-blocker> It doesn't need a preference. It doesn't need shift-click! Mute is already a toggle. Instead of shift clicking on a second solo, just ordinary click on the mute of the additional track you want to solo to get your 'duet'. Where Bjoern and others who want more from mute/solo are coming from, is that they like mute/solo to achieve an additional function of remembering useful combinations of muted tracks. If solo 'takes over' from mute, then mute can 'remember' a handy setting. To my mind that's where the problem comes from. That use conflicts. Solo is/should-be just a convenient way to set mute quickly. We want a more general way to save/restore handy settings. A great feature for the future would be memo-dots, where you can remember a lot of settings, like track heights, zoom factor, scroll position, mute/solo status, selection status, pan settings... and go back to them with one click. We make more work for ourselves and a more confusing interface by doing these as special cases. </not-a-release-blocker> > 2) minor, but are you able to advise further on Truncate Audio, as IMHO > what we have now is way inferior to what we had before. If not everyone > can hear the artefacts with low thresholds should not the user decide > whether to hear them or not? Simply disallow zero as an input value and > note it in the dialogue if the original major destruction of the audio with > a zero parameter set can't be fixed? <not-a-release-blocker> Given the reason that Truncate-Silence is failing on 0 ms, It will/should also 'mangle sound' on 1 ms for below 500 Hz signal, 2ms for 250 Hz and below, 3ms below 125 Hz etc. I'll go as low as 17ms, since you feel 100ms is too conservative. I think it's OK for people to discover that 0ms, 1ms, 7ms and 17ms 'do the same thing'. It doesn't need a note in the dialogue nor a special case mechanism to disable the effect. </not-a-release-blocker> > Gale |
From: Gale A. <ga...@au...> - 2007-09-22 18:16:52
|
| From James Crook <cr...@in...> | Sat, 22 Sep 2007 12:22:09 +0100 | Subject: [Audacity-devel] Checklist - Windows build | > Latency correction in the Preferences (as we now have it, | > with positive values) | > will shift back the audio by the amount the user states. If | > he enters 1000 ms | > for whatever reason, that's what he'll get and very likely some | > real audio that | > should have been part of the recording will be lost, unless shifting behind | > zero is reinstated. If reinstated, then the user will see the white arrows | > indicating audio is behind zero and may time shift the audio back. Unless | > Markus says it's impossible, I don't see why Audacity could not align the | > start | > of such a behind zero recording with zero itself (this change could be made | > post 1.3.4 if needs be). | | Moving the newly recorded audio so it starts before zero is better than | moving everything else! So I would not be in favour of planning to | 'move everything else' automatically. I don't understand what you mean by "everything else". Markus is concerned if audio is shifted behind zero users may not realise that (at least I think that is one of his worries). All I was suggesting is that the recorded track *only* is realigned with zero, then the user can sort it out with time shift tool if he needs to. However I don't regard this as very important, the crucial thing I think is that we reinstate shifting behind zero so that we don't wantonly throw away users' recordings if they record streaming audio with tracks on screen and/or make a mess of the latency settings. | > | > * Fix: Jorge's Mis-selection of sample rate as 'default' when card | > | > can't support file's rate. .... | > | | > | Correct me if I'm wrong, but this isn't a regression is it? In that | > | case we've lived with it before, and we can continue to do so. I vote | > | we demote this to a priority aim-to - i.e. it probably won't get done | > now. | > It depends what OS we are looking at. On Windows which we are discussing | > here, the 1.3.3 behaviour is identical to that in 1.3.2 (file at unsupported | > rate is imported at Default rate), although no one other than me has | > verified | > that AFIK. Jorge's apparent behaviour in 1.3.3 that he originally reported | > * is * a change on 1.3.2 i.e. as I understand it, he is always getting his | > Project Rate | > set to the rate of the imported file, irrespective of the imported file's | > rate. As discussed, this behaviour is preferred for 1.4.0 on all platforms, | > presumably as an essential, with a Preference to always force Project Rate | > to Default Rate to be added post 1.4.0 (currently "not aiming") | | Here I'm more concerned about a regression relative to 1.2.6. That | would make it a roadblock to release. It's sounds like we should demote | this to an aim to. On Windows nothing has changed since 1.2.6 - i.e. in 1.2.6, 1.3.2 and 1.3.3, if you import a file at an unsupported rate e.g. 34 100 Hz, then the Project Rate will not change from what it is currently set to (which will probably be the default sample rate but may not be). Jorge appeared on Linux to get different behaviour in 1.2.6 so that Project Rate always respected the rate of the imported file even if its rate was unsupported (Jorge must correct me if I am misinterpreting his posts). So to the extent that Richard found a case on Linux where an imported file at an unsupported rate left the Project Rate at the default, that is a regression on Linux. So we have different OS'es apparently behaving differently with a possible regression for some users on Linux as reported by Richard. What we want is for all platforms to have the rate of the imported file always respected (with a future preference for the user to over-ride this). I agree this is not an essential so I will demote to priority aim to as you suggest. | > 1) is it easy to work in a Preference, shift-click on "Solo" (or whatever) | > to your ideas on Mute/Solo, so that users have some way to retain multiple | > solo buttons whilst keeping all your other ideas - including making mute and | > solo mutually exclusive (a track can't be both muted and solo)? Bjoern | > had a concern that we should not unmute when soloing but he has not yet | > specified where your ideas would not work for him. Presumably everyone | > else is in favour? | | <not-a-release-blocker> | It doesn't need a preference. It doesn't need shift-click! Mute is | already a toggle. Instead of shift clicking on a second solo, just | ordinary click on the mute of the additional track you want to solo to | get your 'duet'. James, the point is that lack of multiple solo will be unpopular with users with a lot of tracks where they want to listen to just a few of them (because if no tracks are currently muted, they will have a large number of tracks to mute in order to get their few solos). However if they can go to a "mute all" situation with one action, then that is another solution as then they just unmute the two they want for their duet. I am very strongly in favour of the simple change you want to make. I think the above is a stumbling block though not so important as letting the user go with one click from hearing one track as solo to another as solo. So how about a "mute all" on the fly somehow - a hotkey? | Where Bjoern and others who want more from mute/solo are coming from, is | that they like mute/solo to achieve an additional function of | remembering useful combinations of muted tracks. If solo 'takes over' | from mute, then mute can 'remember' a handy setting. To my mind that's | where the problem comes from. That use conflicts. Solo is/should-be | just a convenient way to set mute quickly. We want a more general way | to save/restore handy settings. Completely agree. This should not be a stumbling block to what you suggested. | > 2) minor, but are you able to advise further on Truncate Audio, as IMHO | > what we have now is way inferior to what we had before. If not everyone | > can hear the artefacts with low thresholds should not the user decide | > whether to hear them or not? Simply disallow zero as an input value and | > note it in the dialogue if the original major destruction of the audio with | > a zero parameter set can't be fixed? | | <not-a-release-blocker> | | Given the reason that Truncate-Silence is failing on 0 ms, It | will/should also 'mangle sound' on 1 ms for below 500 Hz signal, 2ms for | 250 Hz and below, 3ms below 125 Hz etc. | I'll go as low as 17ms, since you feel 100ms is too conservative. I | think it's OK for people to discover that 0ms, 1ms, 7ms and 17ms 'do the | same thing'. It doesn't need a note in the dialogue nor a special case | mechanism to disable the effect. Completely disagree I'm afraid. People who discover that when they ask for 25ms or 1 ms they only get 100 ms will think there is a bug in the effect and will quite properly be writing to -help list with which Richard and I will have to deal. If the effect can't accept some input values, this should be explicit to the user either by disallowing the input with a helpful error message, or stated on the effect or in the documentation. Unless you have already, please import some actual music into the released 1.3.3, silence a portion of it then truncate the silence to 1ms. How bad does it sound to you? Now truncate it to 0ms. Isn't it far worse than truncating to 1 ms? I also tried creating a 440 Hz tone in 1.3.3 released version, silenced a few seconds then truncated the silence to 1ms. To me, there is a slight click generated at the truncation point, but no significant degradation of the tone. If I truncate to 100 ms there is a double click but the tone does not sound any "better" to me than with 1ms truncation. If I truncate a real piece of music to 1ms (I have tried a dozen different pieces) I hear no click and (again to me) no significant degradation of audio (frankly I can hear none at all). Unfortunately people do use truncate silence on music and do use it to try and remove all (audible) silence. IMHO it does a good job as long as you don't go down to 0ms and this will be an unpopular reduction in functionality. Gale Outbound message virus free. Tested on: 9/22/2007 7:16:54 PM |
From: James C. <cr...@in...> - 2007-09-22 22:23:10
|
> Gale Andrews wrote: >> James Crook wrote: > | Moving the newly recorded audio so it starts before zero is better than > | moving everything else! So I would not be in favour of planning to > | 'move everything else' automatically. > I don't understand what you mean by "everything else". If you move the recorded track right to start at zero, then you are no longer in sync... You *would* need to move the audio you were play-throughing to be back in sync. A horrible solution. > Markus is concerned > if audio is shifted behind zero users may not realise that (at least I think that > is one of his worries). All I was suggesting is that the recorded track *only* is > realigned with zero, then the user can sort it out with time shift tool if he needs > to. But if you don't move the other audio, then your 'latency correction' hasn't helped and you are out of sync??? You will just get queries "Why doesn't latency correction work?". > | > | > * Fix: Jorge's Mis-selection of sample rate as 'default' when card > | > | > can't support file's rate. .... > I agree this is not an essential so I will demote to priority aim to as you suggest. Good. > James, the point is that lack of multiple solo will be unpopular with users with > a lot of tracks where they want to listen to just a few of them (because if no > tracks are currently muted, they will have a large number of tracks to mute in > order to get their few solos). Not so. They click one solo. That mutes everything but the one track. Now they unmute one-by-one the remaining tracks which they want to hear. Two clicks to select tracks for a duet. > However if they can go to a "mute all" situation > with one action, then that is another solution as then they just unmute the two > they want for their duet. I am very strongly in favour of the simple change you > want to make. I think the above is a stumbling block though not so important > as letting the user go with one click from hearing one track as solo to another > as solo. So how about a "mute all" on the fly somehow - a hotkey? It's the ability to unmute-all that needs some attention. My suggestion was that soloing an already solo track is one way to achieve that. Sure we could have hotkeys for mute-all and unmute-all. > Unless you have already, please import some actual music into the released > 1.3.3, silence a portion of it then truncate the silence to 1ms. How bad does it > sound to you? Now truncate it to 0ms. Isn't it far worse than truncating to > 1 ms? You are right Gale. Looking at pure tones, a 1ms interval should be damaging audio rather badly - especially when the threshold for silence is only a little below the level of the sound. However, in actual practice I can only get it to make relatively minor crackly-damage and that by playing with parameters until I get a particularly bad case. TruncSilence should excise more audio than it does in these cases, but I'm not complaining! The flaw is working in our favour. For music sounds, provided the noise threshold wasn't too low, a 1-5ms interval was OK on the parts of a song with instrumental backing. It wrecked tempo on the quieter bits and lost lead-in and lead-out, but that's all understandable. 0ms is the only real problem case. Of course I'd rather make 0ms behave like 1ms as that's less work, but given your tenacity on this one :-) I guess I'd better go with: Text that appears on the dialog saying 'Duration must be at least 1ms' when the value is too low, and greying out of the button. I'll mark it in as a [JC] essential next time I visit the release checklist. Thanks Gale. --James. |
From: Gale A. <ga...@au...> - 2007-09-23 02:10:22
|
| From James Crook <cr...@in...>=20 | Sat, 22 Sep 2007 23:25:22 +0100 | Subject: [Audacity-devel] Checklist - Windows build | > Gale Andrews wrote: | >> James Crook wrote: | > | Moving the newly recorded audio so it starts before zero is | > | better than moving everything else! So I would not be in | > | favour of planning to 'move everything else' automatically. | > | > I don't understand what you mean by "everything else".=20 |=20 | If you move the recorded track right to start at zero, then you are n= o=20 | longer in sync... You *would* need to move the audio you were=20 | play-throughing to be back in sync. A horrible solution. | .. If you don't move the other audio, then your 'latency correction'= =20 | hasn't helped and you are out of sync??? You will just get queries= =20 | "Why doesn't latency correction work?". I think we are at cross purposes here. The main scenario I'm concerned=20 with is a user error setting the latency correction badly in excess which= =20 results in audio going behind zero and being irreplaceably lost; the synchronisation is going to be way out in that case anyway. Also, we=20 don't know how PortAudio correction will work on all systems when=20 enabled. Who can say it will never create an excessive correction? My only concern is that no recorded audio should ever be discarded. You=20 say you prefer shifting behind zero is permitted with no deletion, so the= =20 two of us and JP are in accord there. Markus and possibly Leland are not=20 - it's a shame we cannot have his views. I remember him saying "think anyone will notice it's gone?".....=20 Do you have a view James on the question of whether backwards latency=20 correction should be called positive in the preferences in reversal of the= =20 previous meaning? I still believe this change is counter-intuitive when you= =20 compare with shifting the audio with the time shift tool, but as long as I= =20 can explain it in the preferences, I'm quite happy to go with it - and it d= oes save the user adding the minus symbol. =2E =20 | > James, the point is that lack of multiple solo will be unpopular wi= th=20 | > users with | > a lot of tracks where they want to listen to just a few of them=20 | > (because if no tracks are currently muted, they will have a large | > number of tracks to mute in order to get their few solos).=20 |=20 | Not so. They click one solo. That mutes everything but the one trac= k.=20 | Now they unmute one-by-one the remaining tracks which they want to he= ar. |=20 | Two clicks to select tracks for a duet. =20 OK, so when you solo the first track, this depresses the mute buttons on al= l=20 the other tracks because they are now properly interlocked? It will need= =20 carefully documenting, and a little getting used to for some, but if that's= what you mean, that's excellent to my mind. As for mute-all/unmute-all shortcut= s, soloing an already solo track seemingly must unmute all by definition, if I= am envisaging this correctly, but there is no one-click way to unmute all is t= here?=20 So to the extent that someone would still want to do that (I can think of a few reasons) then we probably do need an unmute-all hotkey. So pending any other comments, can we get this done if we agree in principle post=20 1.4.0 to look at retaining mute patterns in some way? | > Unless you have already, please import some actual music into the r= eleased=20 | > 1.3.3, silence a portion of it then truncate the silence to 1ms. Ho= w bad | > does it sound to you? Now truncate it to 0ms. Isn't it far worse th= an | > truncating to 1 ms? =20 |=20 | Looking at pure tones, a 1ms interval should be damaging audio rather | badly - especially when the threshold for silence is only a little be= low the | level of the sound. However, in actual practice I can only get it to= make | relatively minor crackly-damage and that by playing with parameters= =20 | until I get a particularly bad case.=20 |=20 | TruncSilence should excise more audio than it does in these cases, bu= t=20 | I'm not complaining! The flaw is working in our favour. For music= =20 | sounds, provided the noise threshold wasn't too low, a 1-5ms interval= =20 | was OK on the parts of a song with instrumental backing. It wrecked= =20 | tempo on the quieter bits and lost lead-in and lead-out, but that's a= ll=20 | understandable. 0ms is the only real problem case. | Of course I'd rather make 0ms behave like 1ms as that's less work, bu= t=20 | given your tenacity on this one :-) I guess I'd better go with: | Text that appears on the dialog saying 'Duration must be at least 1ms= '=20 | when the value is too low, and greying out of the button. | I'll mark it in as a [JC] essential next time I visit the release che= cklist. I think we're both right here actually. I have been getting the excellent= =20 results I have been by using real silence, only selecting the area around= =20 the silence for running the effect, and using thresholds with high negative values. I can easily hear the problems when using higher thresholds and=20 in lead-ins/outs. So (I think) you are going to disallow 0ms for lower =20 thresholds as you judge best, and when this occurs the button greys and your message appears "Max Silent Duration must be at least =20 1 millisecond with this threshold value" or similar. That's fine (I do=20 suggest you spell out millisecond though, for the idiots). =20 Thanks=20 Gale Outbound message virus free. Tested on: 9/23/2007 3:10:25 AM |
From: James C. <cr...@in...> - 2007-09-23 11:38:01
|
Gale Andrews wrote: > I think we are at cross purposes here. The main scenario I'm concerned > with is a user error setting the latency correction badly in excess which > results in audio going behind zero and being irreplaceably lost; the > synchronisation is going to be way out in that case anyway. What criterion do you suggest we use to decide whether to shift newly recorded audio (rightwards) to zero?? If we always do it when there is any audio at negative time, then latency correction does nothing for us when playing through from audio that starts at zero.... Do we then need a warning dialog to say 'Latency correction will not be applied as it will result in audio before zero time. If you want to actually have a latency correction, you will need to shift the audio you are playing through first.' YUCK! Losing a latency time worth of audio or shifting before zero (and not losing) are better solutions. I think always shifting right on negative time sound to prevent losing audio (which might be several seconds if they have a silly latency correction) is a bad solution. I'd rather remove the latency correction preference altogether than do that shift right. > My > only concern is that no recorded audio should ever be discarded. You > say you prefer shifting behind zero is permitted with no deletion, so the > two of us and JP are in accord there. - What (I believe) we have now, i.e. sound lost, is acceptable. - Shifting right is not. - Audio before zero is much better. - If removing the latency correction pref altogether is not acceptable then the checklist needs updating to reflect that. > Markus and possibly Leland are not > - it's a shame we cannot have his views. I remember him saying "think > anyone will notice it's gone?"..... You could contact Leland off list... > Do you have a view James on the question of whether backwards latency > correction should be called positive in the preferences in reversal of the > previous meaning? I have a mild preference for +ve value as it saves needing the '-' sign. > I still believe this change is counter-intuitive... [snip] but... [snip] > I'm quite happy to go with it - and it does save the user adding the minus symbol. > OK, so when you solo the first track, this depresses the mute buttons on all > the other tracks because they are now properly interlocked? Yes. > but there is no one-click way to unmute all is there? No. Only a two-click (on same solo button) way. > So to the extent that someone would still want to do that (I can think of > a few reasons) then we probably do need an unmute-all hotkey. Yes. > So pending any other comments, can we get this done if we agree in principle post > 1.4.0 to look at retaining mute patterns in some way? Yes. But it is an aim-to, not a priority aim to. It may not make the cut. On the other hand, it is a change I would like to make, and it is a change that goes well with the recent change in size of the mute-solo buttons. > So (I think) you are going to disallow 0ms for lower > thresholds as you judge best, Disallow 0ms for all thresholds. Most useful waveforms cross zero somewhere :-) so are below threshold for 0ms or more. Hmm. TrucSilence probably needs a remove-DC-bias before it. Another day I guess, not 1.4. > and when this occurs the button greys and > your message appears "Max Silent Duration must be at least > 1 millisecond with this threshold value" or similar. Yes. > That's fine (I do suggest you spell out millisecond though). OK. I'll also update the wiki as we agree now. --James. |
From: Gale A. <ga...@au...> - 2007-09-24 00:53:01
|
Essential Checklist fix: "Crash on record-append - Reported by JP. Append recording when with multiple sample rates, and 'play other track while recording new one' crashes. This being an essential is contingent on our having a reproducible scenario" I have a scenario. Having the Project Rate different to the track rate is not sufficient for the crash: two or more tracks at different rates must be present. * Import a 44 100 Hz file so that Project Rate is 44 100 Hz * Import a second file of a different rate e.g. 22 050 Hz (Project Rate remains at 44 100 Hz) * select all the 44 100 Hz file (so that you don't invoke the crash-with play-other-tracks-if none-selected bug), hold down shift then press Record. * Crash (tried 3 times so replicable). If it helps: if I add a third track at the rate of the first imported file (44 100 Hz), it stops the crash occurring. So I think all the tracks however many they are must be at different rates to cause the crash. You will also find you can't recover the Project properly after the crash, as there is more than one imported file (as per recent discussion). Wiki documented with this scenario. Additionally, I noticed when append-recording with one track only on screen, there is no playback of the track, despite "play other tracks while recording" being enabled. I added this to Checklist as (presumably) a low-priority aim-to, though perhaps this is fixable at the same time? Gale Outbound message virus free. Tested on: 9/24/2007 1:53:00 AM |
From: Martyn S. <mar...@go...> - 2007-09-25 22:27:44
|
Should be fixed now, see 'Re: [Fwd: Re: [Audacity-devel] bug in append record]' thread. Martyn Gale Andrews wrote: > Essential Checklist fix: > > "Crash on record-append - Reported by JP. Append recording when with > multiple sample rates, and 'play other track while recording new one' crashes. > This being an essential is contingent on our having a reproducible scenario" > > I have a scenario. Having the Project Rate different to the track rate is not > sufficient for the crash: two or more tracks at different rates must be present. > > * Import a 44 100 Hz file so that Project Rate is 44 100 Hz > * Import a second file of a different rate e.g. 22 050 Hz > (Project Rate remains at 44 100 Hz) > * select all the 44 100 Hz file (so that you don't invoke the crash-with > play-other-tracks-if none-selected bug), hold down shift then press > Record. > * Crash (tried 3 times so replicable). > > If it helps: if I add a third track at the rate of the first imported file > (44 100 Hz), it stops the crash occurring. So I think all the tracks however > many they are must be at different rates to cause the crash. You will also > find you can't recover the Project properly after the crash, as there is more > than one imported file (as per recent discussion). Wiki documented with this > scenario. > > Additionally, I noticed when append-recording with one track only on > screen, there is no playback of the track, despite "play other tracks > while recording" being enabled. I added this to Checklist as (presumably) > a low-priority aim-to, though perhaps this is fixable at the same time? > > > > Gale > > > > > > > Outbound message virus free. > Tested on: 9/24/2007 1:53:00 AM > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Audacity-devel mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > |
From: JP <pen...@rf...> - 2007-09-25 22:38:58
|
Thanks very much Martyn, we really appreciate it. ~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 > -----Original Message----- > From: aud...@li... > [mailto:aud...@li...] On > Behalf Of Martyn Shaw > Sent: Tuesday, September 25, 2007 6:28 PM > To: aud...@li... > Subject: Re: [Audacity-devel] Crash on record-append > > Should be fixed now, see > 'Re: [Fwd: Re: [Audacity-devel] bug in append record]' thread. > > Martyn > > Gale Andrews wrote: > > Essential Checklist fix: > > > > "Crash on record-append - Reported by JP. Append recording > when with > > multiple sample rates, and 'play other track while > recording new one' crashes. > > This being an essential is contingent on our having a > reproducible scenario" > > > > I have a scenario. Having the Project Rate different to the > track rate > > is not sufficient for the crash: two or more tracks at > different rates must be present. > > > > * Import a 44 100 Hz file so that Project Rate is 44 100 Hz > > * Import a second file of a different rate e.g. 22 050 Hz > > (Project Rate remains at 44 100 Hz) > > * select all the 44 100 Hz file (so that you don't invoke > the crash-with > > play-other-tracks-if none-selected bug), hold down shift > then press > > Record. > > * Crash (tried 3 times so replicable). > > > > If it helps: if I add a third track at the rate of the > first imported > > file > > (44 100 Hz), it stops the crash occurring. So I think all > the tracks > > however many they are must be at different rates to cause > the crash. > > You will also find you can't recover the Project properly after the > > crash, as there is more than one imported file (as per recent > > discussion). Wiki documented with this scenario. > > > > Additionally, I noticed when append-recording with one > track only on > > screen, there is no playback of the track, despite "play > other tracks > > while recording" being enabled. I added this to Checklist as > > (presumably) a low-priority aim-to, though perhaps this is > fixable at the same time? > > > > > > > > Gale > > > > > > > > > > > > > > Outbound message virus free. > > Tested on: 9/24/2007 1:53:00 AM > > > > > > > > > > > ---------------------------------------------------------------------- > > --- This SF.net email is sponsored by: Microsoft Defy all > challenges. > > Microsoft(R) Visual Studio 2005. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > Audacity-devel mailing list > > Aud...@li... > > https://lists.sourceforge.net/lists/listinfo/audacity-devel > > > > -------------------------------------------------------------- > ----------- > This SF.net email is sponsored by: Microsoft Defy all > challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Audacity-devel mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel |
From: Gale A. <ga...@au...> - 2007-09-26 01:37:17
|
| From Martyn Shaw <mar...@go...> | Tue, 25 Sep 2007 23:28:26 +0100 | Subject: [Audacity-devel] Crash on record-append | Should be fixed now, see | 'Re: [Fwd: Re: [Audacity-devel] bug in append record]' thread. | Gale Andrews wrote: | > Essential Checklist fix: | > | > "Crash on record-append - Reported by JP. Append recording when with | > multiple sample rates, and 'play other track while recording new one' | > crashes. Many thanks Martyn, verified and moved to [Done] on the checklist. | > Additionally, I noticed when append-recording... there is no playback | > of the track, despite "play other tracks while recording" being enabled. | > I added this to Checklist as (presumably) a low-priority aim-to... Remains on checklist, as bug still present. Thanks again Gale Outbound message virus free. Tested on: 9/26/2007 2:37:17 AM |
From: Martyn S. <mar...@go...> - 2007-09-27 00:00:21
|
I'm confused. Essential fixes ... * [MM] "Play other tracks while recording new one" causes a crash on press Record (or if no crash, no audio from the played back track is heard) unless a selection area is made in the track to be played. I can't see/hear this, so can't try and fix it. Does it really exist? On what platform? How can I reproduce it? Can we please get more/better details on the wiki? Or here? Aim to ... * Fix (low priority) no playback of tracks occurs when you append-record, even though "play other tracks while recording" is enabled This appears to be the same report, now as an 'Aim to', not an 'Essential fix' Things are not clear enough for this half-wit to act. Sorry Martyn Gale Andrews wrote: > | From Martyn Shaw <mar...@go...> > | Tue, 25 Sep 2007 23:28:26 +0100 > | Subject: [Audacity-devel] Crash on record-append > | Should be fixed now, see > | 'Re: [Fwd: Re: [Audacity-devel] bug in append record]' thread. > | Gale Andrews wrote: > | > Essential Checklist fix: > | > > | > "Crash on record-append - Reported by JP. Append recording when with > | > multiple sample rates, and 'play other track while recording new one' > | > crashes. > > Many thanks Martyn, verified and moved to [Done] on the checklist. > > | > Additionally, I noticed when append-recording... there is no playback > | > of the track, despite "play other tracks while recording" being enabled. > | > I added this to Checklist as (presumably) a low-priority aim-to... > > Remains on checklist, as bug still present. > > > Thanks again > > > Gale > > > > Outbound message virus free. > Tested on: 9/26/2007 2:37:17 AM > > > > |
From: Gale A. <ga...@au...> - 2007-09-27 03:50:30
|
| From Martyn Shaw <mar...@go...> | Thu, 27 Sep 2007 01:01:07 +0100 | Subject: [Audacity-devel] Crash on record-append | Essential fixes | ... | * [MM] "Play other tracks while recording new one" causes a crash | on press Record (or if no crash, no audio from the played back track is | heard) unless a selection area is made in the track to be played. | | I can't see/hear this, so can't try and fix it. Does it really exist? | On what platform? How can I reproduce it? Can we please get | more/better details on the wiki? Or here? It was originally reported by me (Win XP SP2) and James picked it up and put [MM] by it and I "tried" to make it clear (apart from lack of the OS). I had not rechecked since it was reported, as no-one had apparently done anything to address it, but the issue is gone from your 260907 build (yesterday). It was there 12 times out of 12 in your build from the 18th. So essential fixes has become "nada" again, as long as it stays fixed. | Aim to | ... | * Fix (low priority) no playback of tracks occurs when you | append-record, even though "play other tracks while recording" is enabled | | This appears to be the same report, now as an 'Aim to', not an | 'Essential fix' It is not the exactly the same report, as it occurs only when append-recording. The bug above occurred when both recording normally and when append-recording. This append-recording problem still appears in your last uploaded build (as I said yesterday), which has the then uncommitted changes to allow shifting behind zero. To reproduce the issue I can (assuming "play other tracks while recording" is enabled): * Generate 30 second tone * hold down SHIFT while pressing Record. No playback of the tone for me. If you get playback with the changes you just committed and someone else confirms, this one can go as well subject to me double-checking this in the next build I get (though I don't see why the problem should have gone). Thanks Gale Outbound message virus free. Tested on: 9/27/2007 4:50:29 AM |
From: Martyn S. <mar...@go...> - 2007-09-27 21:23:23
|
Gale Andrews wrote: ... > * Generate 30 second tone > * hold down SHIFT while pressing Record. > > No playback of the tone for me. Me neither. Why should I? The head is past the tone so I would not expect it to play. Martyn |
From: Gale A. <ga...@au...> - 2007-09-28 02:06:53
|
| From Martyn Shaw <mar...@go...> | Thu, 27 Sep 2007 22:24:02 +0100 | Subject: [Audacity-devel] Crash on record-append | Gale Andrews wrote: | ... | > * Generate 30 second tone | > * hold down SHIFT while pressing Record. | > | > No playback of the tone for me. | | Me neither. Why should I? The head is past the tone so I would not | expect it to play. Well I wondered after I wrote that whether there is much sense in what I was thinking Audacity might do. I'll try again. Import a 1 minute music file then a 30 seconds music file (exact times don't matter) and line up the shorter track to start at the end of the first one. Have "Play other track" enabled in Preferences. Select first track only, select your mic as input and hold down SHIFT and press Record. Now what I see is that the recording cursor is advancing much more quickly than the recording is being written and sure enough when playback of the 30 seconds is up, I have only got about 5 seconds of squashed recording. Effect > Change Speed makes it sound OK when I have figured what change to apply. Both tracks and the Project Rate are 48 000 Hz, recording is resampled to 44 100 Hz as always here. If I repeat the experiment with stereo mix as input but let the recording run on after 30 seconds, then every 30 seconds it starts to play back and record a squashed version of the 30 second track. If I append-record with "play other tracks" turned off in Preferences, the recording is still squashed. If I place the cursor at the start of the second track, Edit > Select Cursor to End then just press Record, everything is almost right - I get a 30 second recording with either mic or stereo mix. But the recorded track does not stay put (starting at 1 minute on the timeline) but gets pushed back to start at zero (or as modified by the latency correction setting - e.g. if I set latency to push the track back 100ms it jumps back to start at 100ms behind zero). So it looks like this needs addressing at some stage so there is no shift back to zero. Reluctant aim-to for 1.4 or has pretty much anything new that is not essential going to be post 1.4 now? I have repeated all tests six times with identical results. Is the squashed recording more intermittent behaviour/this demon-inhabited computer or sound device, or does anyone else see this? Can I raise something else? "Recent Files" no longer seems to be populated with any imported files at all except .aup so it's regressing again. If I delete audacity.cfg, then 1.2.6 Preferences (otherwise it seems to populate Recent files from there), no imported FLAC/WAV/MP3 will appear in the Recent Files list. In 1.2.6, some audio formats are remembered in the list but not others. When Recent Files does have a list of say MP3s to work with, should it behave like File > Open and open files after the first one on screen in new windows? It does in 1.2.6 but was it ever agreed this was best? Or does it have to do this because .aups in the list must open in new windows? Personally I find this an irritation with other than .aup files. Is the failure to populate Recent Files with non-Project files "post 1.4" - i.e. not a bad enough regression on 1.2.6 to bother with now? Gale Outbound message virus free. Tested on: 9/28/2007 3:06:55 AM |
From: Martyn S. <mar...@go...> - 2007-09-28 19:06:12
|
Gale Andrews wrote: > | From Martyn Shaw <mar...@go...> > | Thu, 27 Sep 2007 22:24:02 +0100 > | Subject: [Audacity-devel] Crash on record-append > | Gale Andrews wrote: > | ... > | > * Generate 30 second tone > | > * hold down SHIFT while pressing Record. > | > > | > No playback of the tone for me. > | > | Me neither. Why should I? The head is past the tone so I would not > | expect it to play. > > Well I wondered after I wrote that whether there is much sense in what I > was thinking Audacity might do. I'll try again. Import a 1 minute music > file then a 30 seconds music file (exact times don't matter) and line up the > shorter track to start at the end of the first one. Have "Play other track" > enabled in Preferences. Select first track only, select your mic as input and > hold down SHIFT and press Record. Now what I see is that the recording > cursor is advancing much more quickly than the recording is being written > and sure enough when playback of the 30 seconds is up, I have only got > about 5 seconds of squashed recording. Effect > Change Speed makes it > sound OK when I have figured what change to apply. Both tracks and the > Project Rate are 48 000 Hz, recording is resampled to 44 100 Hz as always > here. If I repeat the experiment with stereo mix as input but let the recording > run on after 30 seconds, then every 30 seconds it starts to play back and > record a squashed version of the 30 second track. I have heard something similar. Will try and track it down. If I append-record with > "play other tracks" turned off in Preferences, the recording is still squashed. You have several times reported recording and / or playback at the wrong speed. This happened to me once so I updated the device driver for my sound card and it fixed. Just a thought. > If I place the cursor at the start of the second track, Edit > Select Cursor to > End then just press Record, everything is almost right - I get a 30 second > recording with either mic or stereo mix. But the recorded track does not > stay put (starting at 1 minute on the timeline) but gets pushed back to start > at zero (or as modified by the latency correction setting - e.g. if I set latency > to push the track back 100ms it jumps back to start at 100ms behind zero). > So it looks like this needs addressing at some stage so there is no shift back > to zero. Reluctant aim-to for 1.4 or has pretty much anything new that is not > essential going to be post 1.4 now? The jump back to zero is only in the version I posted - it has been fixed now. The jump by the latency amount I noted yesterday "...Latency correction after append-recording should be of the 'Trim' or 'Clear' kind, in my opinion...". I'm thinking about that. > I have repeated all tests six times with identical results. Is the squashed > recording more intermittent behaviour/this demon-inhabited computer or > sound device, or does anyone else see this? I don't see it. Martyn |
From: Gale A. <ga...@au...> - 2007-09-29 03:00:14
|
| From Martyn Shaw <mar...@go...> | Fri, 28 Sep 2007 20:06:55 +0100 | Subject: [Audacity-devel] Crash on record-append | Gale Andrews wrote: | > | From Martyn Shaw <mar...@go...> | > | Thu, 27 Sep 2007 22:24:02 +0100 | > | Subject: [Audacity-devel] Crash on record-append | > | Gale Andrews wrote: | > | ... | > | > * Generate 30 second tone | > | > * hold down SHIFT while pressing Record. | > | > | > | > No playback of the tone for me. | > | | > | Me neither. Why should I? The head is past the tone so I would not | > | expect it to play. | > | > Well I wondered after I wrote that whether there is much sense in what I | > was thinking Audacity might do. I'll try again. Import a 1 minute music | > file then a 30 seconds music file (exact times don't matter) and line up the | > shorter track to start at the end of the first one. Have "Play other track" | > enabled in Preferences. Select first track only, select your mic as input | > and hold down SHIFT and press Record. Now what I see is that the | > recording | > cursor is advancing much more quickly than the recording is being written | > and sure enough when playback of the 30 seconds is up, I have only got | > about 5 seconds of squashed recording. Effect > Change Speed makes it | > sound OK when I have figured what change to apply. Both tracks and the | > Project Rate are 48 000 Hz, recording is resampled to 44 100 Hz as always | > here. If I repeat the experiment with stereo mix as input but let the | > recording run on after 30 seconds, then every 30 seconds it starts to play | > back and record a squashed version of the 30 second track. | | I have heard something similar. Will try and track it down. | | > If I append-record with | > "play other tracks" turned off in Preferences, the recording is still | > squashed. | | You have several times reported recording and / or playback at the wrong | speed. This happened to me once so I updated the device driver for my | sound card and it fixed. Just a thought. Hi Martyn Well I'd be pretty naff if I did not have the best drivers I could given the number of hours I spend a week telling other people to do it :-). Actually I never have reported recording speed problems that I can recall. My issue was Audacity failing to report clipping. As I could not recall speed issues before on this machine, I was suspicious, especially as the problem was *solely* when append-recording. Anyway, above tests were with USB sound card (MS generic drivers as the "proper" ones just won't work with my hardware). I have rebooted and tried again. No speed problem now when append-recording with the USB card. Switched to inbuilt sound (latest drivers) and no speed problem. Both devices have the issue with repeated/corrupted playback when append-recording *after* the head has gone past the audio on the track it was playing. As you have heard this too, it must be so. | The jump by the latency amount I noted yesterday "...Latency correction | after append-recording should be of the 'Trim' or 'Clear' kind, in my | opinion...". I'm thinking about that. I'm not really clear Martyn where your lines of thought are heading. It looked by what you said that by "Trim" you mean truncate? We don't want truncation do we? The checklist item currently suggests: "Prevent latency correction occurring when append-recording, even if set in Preferences, to prevent possibility of "real" audio being shifted behind zero. Actual situation needs noting in the Manual, whether this aim-to is done for 1.4.0 or not". Thanks Martyn Gale Outbound message virus free. Tested on: 9/29/2007 4:00:18 AM |
From: Martyn S. <mar...@go...> - 2007-09-30 00:06:35
|
Gale Andrews wrote: ... > Well I'd be pretty naff if I did not have the best drivers I could given the > number of hours I spend a week telling other people to do it :-). True. Just an idea. Didn't mean to offend ;-). Actually I > never have reported recording speed problems that I can recall. There was something around here about recording always falling a fraction of a second short of what it should. Sorry, must have mis-remembered it. Won't waste time searching for a reference. My issue > was Audacity failing to report clipping. As I could not recall speed issues > before on this machine, I was suspicious, especially as the problem was > *solely* when append-recording. Anyway, above tests were with USB > sound card (MS generic drivers as the "proper" ones just won't work > with my hardware). I have rebooted and tried again. No speed problem > now when append-recording with the USB card. Switched to inbuilt sound > (latest drivers) and no speed problem. Wierd, so a reboot fixed the speed problem? You don't have it any more? Both devices have the issue with > repeated/corrupted playback when append-recording *after* the head > has gone past the audio on the track it was playing. As you have heard > this too, it must be so. Indeed. I have investigated this, found the problem (playing the track you are recording into) and have a fix locally. I want to have a more complete solution before I commit it though. > | The jump by the latency amount I noted yesterday "...Latency correction > | after append-recording should be of the 'Trim' or 'Clear' kind, in my > | opinion...". I'm thinking about that. > > I'm not really clear Martyn where your lines of thought are heading. It looked > by what you said that by "Trim" you mean truncate? We don't want truncation > do we? The checklist item currently suggests: > > "Prevent latency correction occurring when append-recording, even if set in > Preferences, to prevent possibility of "real" audio being shifted behind zero. > Actual situation needs noting in the Manual, whether this aim-to is done for > 1.4.0 or not". Now there's a thing. That is not a very good solution to the problem, I think. I figure it like this: We have 2 tracks recorded/imported, like in your example of a 60s and a 30s track, both starting at zero. Synchronised together, in time. We select the shorter one. We have a +ve or -ve latence in prefs, possibly randomly typed in, or incorrectly concieved. Let's assume that it is correct and causes the recorded bit to move left by the correct amount (-162ms on my version, with tonight's HEAD version). We press shift-record (append-record) and record something, then press 'stop'. Do we want the shorter track, that was synchronised, to be shifted? No. Do we want the newly recorded bit to be in synch with what was listened to while recording it? Yes. Can we shift the new bit back (left)? No, it will overlap with the original bit (and that's not allowed in Audacity, and I think that's correct). What can we do? Leave the original bit of that track where it is and truncate (Clear) the new bit so it's still in synch. That's my way of thinking, and what I'm working on doing. We could pop a warning but it would get annoying for people who knew what they were doing. We could have a 'don't show again'. We could do anything with enough develepers! Don't forget that, in terms of the codebase, a step towards a solution is better than waiting for a perfect solution! TTFN Martyn > Thanks Martyn > > > Gale > > > > > Outbound message virus free. > Tested on: 9/29/2007 4:00:18 AM > > > > |
From: Gale A. <ga...@au...> - 2007-10-01 01:06:02
|
| From Martyn Shaw <mar...@go...> | Sun, 30 Sep 2007 01:07:18 +0100 | Subject: [Audacity-devel] Crash on record-append | | > Well I'd be pretty naff if I did not have the best drivers I could given the | > number of hours I spend a week telling other people to do it :-). | | True. Just an idea. Didn't mean to offend ;-). No offence taken :-) | Actually I | > never have reported recording speed problems that I can recall. | | There was something around here about recording always falling a | fraction of a second short of what it should. Sorry, must have | mis-remembered it. Won't waste time searching for a reference. Yes that was me, but I wasn't thinking of it as a recording speed problem because the last bit of the played back audio is missing in the recording. It's an aim-to on the Checklist: "Fix problem when recording stereo mix from a track in Audacity, about 100ms of the recording is truncated at the end (irrespective of latency correction setting in Preferences)." | My issue | > was Audacity failing to report clipping. As I could not recall speed issues | > before on this machine, I was suspicious, especially as the problem was | > *solely* when append-recording. Anyway, above tests were with USB | > sound card (MS generic drivers as the "proper" ones just won't work | > with my hardware). I have rebooted and tried again. No speed problem | > now when append-recording with the USB card. Switched to inbuilt sound | > (latest drivers) and no speed problem. | | Wierd, so a reboot fixed the speed problem? You don't have it any more? No, and I have never seen the USB card do a classic record at wrong rate before like that. Reboots often do fix things. As I am sure you know, when you try to record you can sometimes find the recording cursor just stays put without recording anything. I still get this problem sometimes after using the computer for more than a day, even on a half decent XP 1.6 GHz system with 1 GB or RAM. But reboot always fixes it. OTOH it may be that the corrupted playback with append-recording issue you just fixed was behind it somehow, given the MS drivers I have to use. | > | The jump by the latency amount I noted yesterday "...Latency | > | correction | > | after append-recording should be of the 'Trim' or 'Clear' kind, in my | > | opinion...". I'm thinking about that. | > | > I'm not really clear Martyn where your lines of thought are heading. It | > looked | > by what you said that by "Trim" you mean truncate? We don't want | > truncation do we? The checklist item currently suggests: | > | > "Prevent latency correction occurring when append-recording, even if set in | > Preferences, to prevent possibility of "real" audio being shifted behind | > zero. Actual situation needs noting in the Manual, whether this aim-to is | > done for 1.4.0 or not". | | Now there's a thing. That is not a very good solution to the problem, I | think. I figure it like this: | | We have 2 tracks recorded/imported, like in your example of a 60s and a | 30s track, both starting at zero. Synchronised together, in time. | We select the shorter one. | We have a +ve or -ve latence in prefs, possibly randomly typed in, or | incorrectly concieved. Let's assume that it is correct and causes the | recorded bit to move left by the correct amount (-162ms on my version, | with tonight's HEAD version). | We press shift-record (append-record) and record something, then press | 'stop'. | | Do we want the shorter track, that was synchronised, to be shifted? No. | Do we want the newly recorded bit to be in synch with what was listened | to while recording it? Yes. | Can we shift the new bit back (left)? No, it will overlap with the | original bit (and that's not allowed in Audacity, and I think that's | correct). | What can we do? Leave the original bit of that track where it is and | truncate (Clear) the new bit so it's still in synch. That's my way of | thinking, and what I'm working on doing. Excellent explanation. I see you have committed a fix so that "latency shift applied to newly recorded bit only". I'll have to wait till I see it as I'm not sure what happens if the user sets a silly, excessive truncation. | We could pop a warning but it would get annoying for people who knew | what they were doing. We could have a 'don't show again'. We could do | anything with enough develepers! I may still cross swords with James on whether the warnings I have in mind (like the one you suggest) are the same as what he is thinking about... | Don't forget that, in terms of the codebase, a step towards a solution | is better than waiting for a perfect solution! Yes I've understood that in many cases (when programming) this may be so. Gale Outbound message virus free. Tested on: 10/1/2007 2:05:45 AM |
From: Martyn S. <mar...@go...> - 2007-10-01 23:38:59
|
Gale Andrews wrote: ... > | Now there's a thing. That is not a very good solution to the problem, I > | think. I figure it like this: > | > | We have 2 tracks recorded/imported, like in your example of a 60s and a > | 30s track, both starting at zero. Synchronised together, in time. > | We select the shorter one. > | We have a +ve or -ve latence in prefs, possibly randomly typed in, or > | incorrectly concieved. Let's assume that it is correct and causes the > | recorded bit to move left by the correct amount (-162ms on my version, > | with tonight's HEAD version). > | We press shift-record (append-record) and record something, then press > | 'stop'. > | > | Do we want the shorter track, that was synchronised, to be shifted? No. > | Do we want the newly recorded bit to be in synch with what was listened > | to while recording it? Yes. > | Can we shift the new bit back (left)? No, it will overlap with the > | original bit (and that's not allowed in Audacity, and I think that's > | correct). > | What can we do? Leave the original bit of that track where it is and > | truncate (Clear) the new bit so it's still in synch. That's my way of > | thinking, and what I'm working on doing. > > Excellent explanation. I see you have committed a fix so that "latency > shift applied to newly recorded bit only". I'll have to wait till I see it as > I'm not sure what happens if the user sets a silly, excessive truncation. Dimbos. (I should remember '50% of the people you meet are below average intelligence'!) We do our best for them (well, maybe ;-) but have to remember the other 50% as well. They lose the amount they asked to lose if they append-record and are listening to other tracks. Otherwise they keep it. Well, that's what I think it does. As you can see by tonight's commit, I am still finding bugs. Zip of current Release HEAD at http://mjshaw.at-uclan.com/audacity.zip for you to try/comment on. TTFN Martyn |
From: Gale A. <ga...@au...> - 2007-10-05 01:41:31
|
| From Martyn Shaw <mar...@go...> | Tue, 02 Oct 2007 00:39:53 +0100 | Subject: [Audacity-devel] Crash on record-append | > | Now there's a thing. That is not a very good solution to the problem, | > | We have 2 tracks recorded/imported, like in your example of a 60s | > | and a | > | 30s track, both starting at zero. Synchronised together, in time. | > | We select the shorter one. | > | We have a +ve or -ve latence in prefs, possibly randomly typed in, or | > | incorrectly concieved. Let's assume that it is correct and causes the | > | recorded bit to move left by the correct amount (-162ms on my version, | > | with tonight's HEAD version). | > | We press shift-record (append-record) and record something, then press | > | 'stop'. | > | Do we want the shorter track, that was synchronised, to be shifted? | > | No. | > | Do we want the newly recorded bit to be in synch with what was | > | listened | > | to while recording it? Yes. | > | Can we shift the new bit back (left)? No, it will overlap with the | > | original bit (and that's not allowed in Audacity, and I think that's | > | correct). | > | What can we do? Leave the original bit of that track where it is | > | and truncate (Clear) the new bit so it's still in synch. That's my | > | way of thinking, and what I'm working on doing. | > | > Excellent explanation. I see you have committed a fix so that "latency | > shift applied to newly recorded bit only". I'll have to wait till I see it | > as I'm not sure what happens if the user sets a silly, excessive | > truncation. | | Dimbos. (I should remember '50% of the people you meet are below | average intelligence'!) We do our best for them (well, maybe ;-) but | have to remember the other 50% as well. | They lose the amount they asked to lose if they append-record and are | listening to other tracks. Otherwise they keep it. Well, that's what I | think it does. As you can see by tonight's commit, I am still finding bugs. | Zip of current Release HEAD at http://mjshaw.at-uclan.com/audacity.zip | for you to try/comment on. Hi Martyn I don't know what the dimbo/cognoscenti ratio is but maybe 30/70 is nearer the mark? I'm allowing for the fact that -help list is unrepresentative, where the ratio "feels" more like 90/10...... The recording and playback seems very smooth now (well done), but of course I can't pretend I like that we're throwing away audio again. Supposing someone is append-recording internet radio? The principle remains (or should do) that we don't throw away audio, the difference being that with append-recording the problem is more difficult because we have nowhere to go "behind". Safest and simplest remains to disallow time shifting when append-recording. Append-recording is a special feature, so special rules apply (but don't extend to throwing audio away). But in some cases, this means the user will have to use Time Shift Tool where they wouldn't have to, should the correction work "exactly" to bring the audio into synchronisation. I have two suggestions, whilst still allowing correction. I don't know about the practicality of either but they are certainly safer: 1) Stop the backwards shifting going any further when it gets to the point of causing truncation (i.e. don't truncate at all; if the backwards shifting would cause shifting behind the original audio, the shifting stops at that point, leaving the start of the new piece aligned with the end of the original piece.) User has to use Time Shift Tool to drag his recorded piece however much forward is needed. 2) Add the truncation to the Undo History (does this amount to the same as 1), i.e. we have to leave all of the recorded audio aligned somewhere, and the best place is with the end of the original audio? Gale Outbound message virus free. Tested on: 10/5/2007 2:41:32 AM |