These are other changes to source code that are deemed essential. We will do all of these for final release candidate for 2.0.
| P2
|
Effects processing/waveform rendering after process completion much slower than 1.3.8.
- GA: Reported several times on Windows. See this thread.
|
| P2
|
Desynchronised playback mixing of short regions in different tracks.
- GA: Not reproducible to order, but likely to occur if repeatedly duplicating short selections in a track. Discussion here.
|
| P2
|
Reverse does not reverse clip boundaries.
- GA: Leads to loss of association between boundaries and original audio, and loss of audio if the clips were separated by white space. See this thread.
|
| P2
|
VST effects permanently in menu once cached, even if unavailable.
- GA: Remove the effect, but it is still in the menu after rescan. Clogs up menu, and very confusing if user forgets effect has been removed then clicks on menu with no result.
|
| P2
|
Edit Labels: "start/end times display as zero" fix breaks screen reading ability.
|
| P2
|
Nyquist effects join separate clips together.
- GA: SBSMS now fixed by DH, leaving the subject problem. See this thread.
- DH: Nyquist will probably need further discussion (was mentioned in the original 'white space' thread I believe) - really processing clips separately could produce artefacts... possible solutions include:
- simply running 'detach at silences' after the effect (I haven't looked at how this works yet but it seems hopeful)
- changing the nyquist interface (e.g. the 'nil means white space' option) which would involve changing all of those plug-ins
- recognising the known plug-ins by filename and dealing with them appropriately (pretty unpleasant temporary solution)
- GA: I always recommend complainants to detach at silences but it now does not seem to work. Do a Nyquist effect like crossfade over white space between clips, then detach and nothing happens, because the silence is not absolute. It's -72 dB noise. Can we fix that? Apart from that, I'm still getting the impression having absolute silence between clips rather than white space would solve a lot of issues.
|
| P2
|
Boundary drawing problem with Generate and SoundTouch
- GA: When applied over existing split lines, these effects sometimes produce a faint or no clip line. This may be demoted, subject to discussion. See this thread.
|
| P2
|
Revert "Metadata before export" and prevent this reversion overwriting aliased files if Metadata Editor is cancelled.
- GA: Users cannot work out they have to click OK in Metadata Editor after clicking File > Export. Some click "Save" so become confused by getting an XML instead of audio file. Extensive discussion on on devel. We need metadata last (this lets it not be pointlessly shown when doing command line export), and then rename aliased files on export in such a way that cancelling the metadata editor does not overwrite them.
- SteveTF suggests a checkbox in Metadata Editor "Do not show before Export step" (linked to the equivalent preference) as a possible quick fix that might let us demote this to P3. Perhaps checkbox is useful even when metadata is fixed to come last.
|
| P2
|
R (Windows) Projects crash when applying repeated effects on zoomed in regions towards the end of audio tracks
- GA: Experienced on Windows XP in one project that crashed regularly on separate days but now won't do so, also several similar anecdotal reports. There is also an implication that Noise Removal is more likely than other effects to trigger the problem. JC suggested and was agreed we should aim to do stress-testing with small block sizes to try and force the problems to occur and (later added) that we should use the scripting feature to do this (improving our chances that we can repeat the problem) .
- JC: A label issue? (I have not seen this crash yet).
- GA: Without labels in my case, with in others, so believed that labels not relevant.
|
| P2
|
Cursor jumps to start of scroll after playback cursor goes past scroll
- GA: Import a file, place cursor in centre and zoom in four or five times. Then play a few seconds of audio so that the cursor goes past the scroll. Press Space and the timeline remains where stopped (maybe OK). Press Space again and playback restarts from original point but that is now at far left of scroll, not in the middle. The context preceding that playback position is now lost, requiring a fiddly drag back on the horizontal scrollbar, or a zoom out and back in. Or, you must draw a selection region when you may not want to do so. Very irritating for repeated zoomed-in editing at one spot.
- JC: This is a P4, or better still a feature request for improved scrolling/zooming behaviour. Let's get some detailed usability enhancements written up for a GSoC 2010 idea? Then drop this as a P2. In this area I'd see 'zoom to selection' should be 90% not 100% zoom, so that we get context, plus also option for smooth scroll on sufficiently fast machines. Can we replace this P2 with a detailed/motivated feature request?
- GA: Need time to consider exactly what may or may not be a feature request, however I and several others regard the subject issue as excessively disruptive to "repeat editing" workflow, and completely unacceptable. I've sometimes actually exported WAV and used other editors in order to be free of it.
|
| P2
|
Labels cannot be repeated
- RA: This causes an apparent bug because when you repeat a labelled selection, the labels don't get repeated. I presume this would be a relatively simple issue to fix.
|
| P2
|
SBSMS, Change Speed, Change Tempo do not keep labels in sync.
- Turn linking on, create 30 seconds default tone, select 5 - 10 seconds and Amplify by -20 dB to see it
- Place label at 15 seconds, select 3 - 12 seconds and Effect > Sliding Time Scale (20% start and end tempo change), or Change Speed or Change Tempo (20% change)
- Label does not move. Labels do move with Repeat in the above scenario, and do move with Reverse if label included in selection region.
|
| P2
|
Truncate Silence does not keep labels in sync
- RA: If a single track is being processed by the Truncate Silence effect, the linked label track is not changed to match. This should be simple to fix for the case where there is only one audio track and the associated label track. This bug does not cover the case where there are multiple audio tracks selected for truncation - that is a much lower priority bug.
- To illustrate, generate a 30 seconds DTMF sequence
- Add labels to some visually obvious places on the waveform
- Select the audio, and Truncate Silence
- Notice the labels haven't moved, when they should have.
|
| P2
|
(Windows 7) Runtime Error Program: (location) R6034 on launching Audacity.
- GA: Fixable by user changing compatibility mode to Vista SP2 or XP SP3. Reports where this error occurs say Audacity installs without compatibility, but that isn't in itself a condition to reproduce it.
|
| P2
|
(Windows Vista, 7) Input sources cannot be selected in Mixer Toolbar.
- GA: A significant problem for support workers. On some systems, running Audacity in compatibility mode for XP seems to make the inputs appear in Mixer Toolbar and work/be selectable. Best solution could be to integrate Device Toolbar into Mixer Toolbar, making sources appear as separate devices for all Windows versions, with the sliders above the respective dropdown. Cheaper short-term solution may be to turn Device Toolbar back on as it is. See proposal.
|
| P3
|
(Windows Vista, 7) Audacity input/output level sliders act independently of/incorrectly with system level sliders.
Symptoms:
- Achieved recorded level only matches level indicated on the Recording VU meter if the Audacity input slider is at 100%. (DB finds similar behaviour on XP with Logitech USB microphone, but GA can't reproduce with USB external sound cards).
- (DB finds this only on Vista) Launch Audacity > Record > Stop > adjust the system input level > Record again; or Launch > adjust system input level > Record resets system level to that before the adjustment, unless monitoring is on. Please test with both motherboard and external USB devices. Adjusting system slider is necessary if it happens to be set above clipping level because lowering the Audacity slider only scales down the clipped signal instead of lowering the system slider. Especially confusing for VI users.
|
| P2
|
√ (Linux only) Crash undoing a label edit, or repeatedly undoing/redoing addition of a label or a label track.
- LLL: This is (probably) fixed now...just needs verification.
- GA: It seems identical characters in the label names is something to do with it, and Undo/Redo of label edits is still very unstable. I found this scenario gives me a replicable crash on Ubuntu CVS ANSI build:
- Open Audacity and create a 30 second sine tone
- Click at 3 seconds, CTRL + B, type "ase1" (without quotes) and ENTER
- Click at 8 seconds, CTRL + B, type "ase2" (without quotes) and ENTER
- Edit > Undo three times, it should crash on "Undo Label", if not before.
Note: do not make any typos entering the labels or the bug may not reproduce.
- Launch Audacity and add a label track
- Delete the label track by clicking on the [X]
- If it does not crash, try pressing CTRL+Z to undo, then click on the label track [X]. Repeat as necessary.
- GA: Removed separate P4 "Intermittent crashes removing a label track" as it would appear this is the same bug and should be dealt with at the same time. That P4 was commented:
- Adding a Label Track causes Edit > Paste to flicker (the code does enable it), then closing the Label Track causes a replicable crash (reported by Darren)
- Removing an audio track then a label track may crash multi-track projects, reported by Zach.
- GA: Fixed by LL but all known repeatable scenarios should be tested before this is removed.
|
| P3
|
R Unreliable project re-opening with orphaned and missing blockfile errors.
- GA: There are reports every week of users losing data correctly reopening a 1.3 .aup file in the exact same 1.3 version they created it in. "Orphaned" or "missing" blockfile errors are received and when users accept the "recommended" course to delete, the project is silenced. This frequency of data loss is not acceptable in 1.4.0. We should be on the alert for these issues, and as soon as steps to reproduce are found, escalate the specific problem to P2. One definite scenario where this has been reported is having multiple projects open, and blockfiles are saved to the wrong _data folder. GA has not yet managed to replicate it, though still has some more reported steps to try and do so...
|
| P3
|
R (reported on Mac) Unreliable project re-opening due to duplicate attributes
- GA: When a saved project is re-opened it fails with "duplicate attribute" error. Almost always involves imported MP3s; the .aup file shows one or more tags with two "name" attributes, for example <tag name="ARTIST" name="ARTIST"/>. Changing second "name" to "value" allows project to re-open. GA (Windows) and a Mac tester have tried to reproduce this with an MP3 that created this issue for one user, but the projects re-opened perfectly. Bug also reported to occur if a diacritic is included in a label.
- GA: One report from CVS on Mac 06 July 09 finds a project with diacritics in labels that saved in 1.3.7 with duplicate attributes saves correctly in CVS.
|
| P3
|
Unreliable Automatic Crash Recovery.
- LL: I've seen some really strange (attempted) recoveries. I haven't yet looked into them, but I shall soon since my wife is complaining about it as well.
- GA: These known problems have been reported. They should be verified and escalated to P2 if valid:
- If a crash occurs with two tracks open, multiple projects are recovered
- Recovery fails if a track is imported then another added after the autosave interval
- Complete recovery failures (empty projects) seen on single tracks which are only generated tones.
- (Mac) freeze on Intel Macs when starting recovery
- (Mac) (Intel and PPC) "Junk after document" warnings then recovered project is empty. See here and download here an example auto save file and _data folder.
|
| P3
|
R AIFF files created by Audacity from recorded or generated data import intermittently (but at times very frequently) as noise - files play fine in other software.
- GA: Much of the time, 1.3.7 or later on Windows cannot be relied on to import files exported with the explicit "AIFF (Apple) signed 16 bit PCM" filter. Appears to affect exports from recorded data (at any Defauit Sample Rate), or from tones generated at 24-bit. Same problem occurs with the AIFF 24-bit option accessed with "Options" button, but not apparently the comparable 16-bit option. Export Multiple seems affected the same way as regular export. Tested at 44100 Hz, reading directly. On Mac, a user 22 March 09 reports 1.3.7 "suddenly" producing noise when importing AIFF files where it did not before in many similar imports - user changed default sample format to 24-bit at about the same time. More details here.
- LL: Gale, have you been able to find a pattern to recreate this? I've tried numerous variations on OSX and Windows and it always seems to import ok.
- GA: Are you using a release build? In ANSI Release from HEAD, I created a chirp tone in 24-bit quality, recorded it using stereo mix then exported only the recorded track using the explicit (no options available) AIFF (Apple) signed 16-bit PCM choice. I changed Quality to 32-bit, closed the tracks and repeated the generation, record and export. I am not getting noise on importing the files back into Audacity but what I can replicate is that about half the time the files will crash both HEAD and 1.3.7 Unicode Release; if they don't crash they import properly. So behaviour compared to when I last tested is not the same. I have tried importing with the "All supported files" and "FFmpeg-compatible files" filter and the problem is identical. In 1.2.6 I can import these files dozens of times without problem.
|
| P3
|
Automatic Crash Recovery: disregards track zoom level and position.
- GA: Always opens tracks at normal zoom level viewed from time zero.
- Import a 3 minute or longer file into fresh project, which fits to project
- Force quit and recover, and first 10 seconds of track reopens from h=0
- Also replicable by generating 30 seconds tone, zooming into a selection in the middle, wait the autosave interval and force quit; again recovered track shows first 10 seconds from h=0
|
| P3
|
Time Track disables audio/label linking.
- Add a tone of 30 seconds in a clean project with linking enabled
- Select 5 - 10 seconds, CTRL+B and name label
- Tracks > Add New > Time Track
- Select 2 - 4 seconds in the tone and Edit > Cut; audio is cut but label does not move
- Edit > Undo
- Remove Time Track and repeat step 4; label moves back to respect cut audio
|
| P3
|
All Edit menu items to be consistently enabled and work consistently when select-all-on-none enabled.
- GA: Demoted from P2 because has been significantly improved, but still inconsistencies between enabled items when track is selected or not, and when it isn't selected but cursor is or isn't in track. See this thread.
|
| P3
|
Label tracks: typing "j" or"k" in a label may activate the "move cursor" shortcut instead.
- GA: Not reproducible to order, but very likely to occur with large numbers of labels in a track. Once it occurs, typing "j" or "k" in any label in that track will move the cursor to start/end of the track.
|
| P3
|
Changes in available devices not detected without restart.
- GA: A significant reason for users' USB devices not appearing in Audio I/O Preferences.
|
| P3
|
(reported on Windows) Timer Record unreliable with recordings straddling midnight
- GA: If recording starts on one day and end on another, recordings may carry on after scheduled end time and cannot be cancelled, requiring a force quit of the application. Elapsed and remaining time will appear frozen at some values consistent with the schedule. No repeatable scenario is known, but for those regularly scheduling midnight spans, the freeze occurs quite regularly. A system clock change is a possible explanation (see next item).
|
| P3
|
(reported on Windows) Timer Record cannot maintain scheduled duration if system clock changes
- GA: Schedule a five minute recording for immediate start (start time immaterial), OK, then change system clock to one minute before end of recording. Elapsed time and remaining time will jump to reflect changed system time, and recording will end having produced just over one minute of recording.
Schedule that recording exactly the same and change system time to one minute after the end of the recording. With 1.3.8 Alpha from 04 June 09, recording will cease immediately, having produced a few seconds of recording. In a previous test of 1.3.8 Alpha from 29 April 09, an hour long recording straddling midnight had its elapsed and remaining times frozen when system clock changed to after end of recording, and carried on after originally intended duration, but could be cancelled. Repeating that same hour long test straddling midnight in 04 June 09 build simply aborts recording when time changes, yet Timer Record code did not change between those dates. Are these fixable by relying on a Widgets timer for duration? Many people synchronize system time to online atomic clocks (Windows XP does it by default).
|
| P3
|
Modal block circumventable using File > New (Mac only) or shortcuts, leading to risk of crash. See this thread.
|
| P3
|
Muting specific time-shifted mono tracks when exporting produces audio at wrong point on timeline in exported file if muted tracks are to left of unmuted.
|
| P3
|
WAVEX (Microsoft) headers: GSM 6.10 files cannot be exported, and U-Law/A-Law files may not be playable.
|
| P3
|
LADSPA Multiband EQ may not be visible in Effect menu (occurs on Windows XP), and crashes soon after opening.
- VJ: The logic needs to be fixed to set rstart to a valid value in all cases, because after initializing rstart to 0, it crashes in LadspaEffect::ProcessStereo().
- LL: I think we've gotten past that, but now there's a crash during cleanup. It's due to a memory overwrite past end of the "comp" array in the mbeq source. It's been fixed in the LV2 version of the plugin, but AFAIK has not been fixed in the v1 plugin. Correctly the logic allows the plugin to process without crash.
|
| P3
|
Residual FFmpeg issues:
- "Select file(s) for batch processing..." dialogue lacks "All Supported files" and "FFmpeg-compatible files" filters
- √ Importing FFmpeg formats when FFmpeg library missing should raise the "FFmpeg not found" error, not the generic "not supported" error. Provisional fix in place, but throws multiple FFmpeg errors per file, then the relevant error for the particular format
- In non-FFmpeg builds, attempting to import FFmpeg-supported formats should give an error that suggests downloading FFmpeg. Impossible to fix completely without breaking Importer abstraction: in non-FFmpeg builds ImportFFmpeg plugin does not exists and cannot suggest anything to user, while Importer should not know which formats are supported by ImportFFmpeg, thus being unable to suggest anything either.
|
| P3
|
On-Demand: when importing a mixture of uncompressed and compressed files, on-demand loading does not start until normal import of the compressed files completes, if the names of the compressed files come earlier in the alphabet.
- GA: On Windows, video files with a preceding name which similarly held up on-demand loading are as of 07 Oct 08 now importing second when dragged in, so the OD file is not delayed, but the tracks are now out of alphabetical order in the track list. Also, correct alphabetical order when using File > Open or Import now depends (on Windows) on the order the files are selected in. GA suggests therefore we could prioritise OD files to import first, then re-order the non-OD files in the track list if needed.
- MC: Fixed 14 Dec 08.
- GA: 24 Jan 08 - not fixed on Windows, except that files now import in alphabetical order irrespective of the order they were selected in. The basic problem remains: using "All supported files" filter, any compressed file (audio or video) that has a preceding name prevents OD loading of an uncompressed file with a following name. until the compressed file has loaded. So, much of the benefit of OD loading is lost.
- MC: Discussed in Feb. 09 as resolved for the time being, but the discussion is still open. The implemented solution is different from planned to minimize UI blockage: Order of sort depends on loading method (if open is used, OD imports first).
- GA: Order of sort depends on loading method on Mac, but on Windows the non-OD file always comes first with both drag/import and open. Therefore, sort order is always wrong if the non-OD file comes later in the alphabet, and we're not getting any benefit on Windows of OD files loading first. Do you see a way of getting OD to come first on Windows when using Open or context-menu opening? And is a resort after load practical? Out of order loading remains I think a P3 issue in itself.
- MC: I forgot about the windows open behavior - it should be different. I just verified it on the mac, so I will need help or access to a windows machine to debug this. But in general the non OD files come first so that the UI isn't blocked while the OD files are being loaded, and thus the user can have the most time interacting with with the project while the files are being loaded. The new method still has sorted order, but its new sort hierarchy is filetype first, then name second, which seems like a reasonable behavior to me. A post-resort of the tracks seems actually disorienting, since the user is watching them being placed in this order as the files import. Thoughts?
- GA: Yes thinking about it, I agree a post-load resort probably would be disorienting. I'm just conscious though of complaints about not importing in file name order, which I think is what the user will be aware of. If we drag in B.mp3 and A.wav, can we place A.wav above B.mp3 to begin with, when it starts to load?
|
| P3
|
√ Preferences window appears broken until you tab into an individual pane.
- GA: OK button appears coloured bold and indicated as default when a tab is selected in the left-hand panel, but does not respond. See this thread.
- GA: Patch to fix this committed, just needs verifying as working by someone on Mac or Linux.
|
| P3
|
When changing language in Preferences, some elements don't change until restart. Affects Audio Track at the top of the Track Drop-down menu, and the toolbars tooltips (except Selection Bar).
- LL: It looks like this has been partially fixed...the track menus now change, but tooltips are still an issue.
- LL: This should now be fixed...just needs verification.
- GA: Still an issue with generic track name ("Audio Track" in English) and Meter Toolbar channel names not changing, and with Selection Toolbar elements running into each other: after changing from English to French; then restarting and changing from French to English.
|
| P3
|
R Pressing Play (but not Space) or clicking on the timeline in a second project when another is already playing stops playback of the first project.
- zachelko: On Windows with Audacity 1.2.6 I'm not experiencing this. However, what seems to happen is that if a track in one project is playing and you attempt to play a track in another project, the play button does nothing and the track isn't started. Was this possibly the "fix" ?
- GA: Because 1.2.6 does not have this problem, the bug is marked R , denoting it is a regression against 1.2.6. To replicate all issues on this list and Release checklist not aiming for 1.4, please test against latest CVS HEAD.
- zachelko: This issue is deeper than just the "Play" function. Pressing Play, Pause, or Stop in another window while a track is playing in a different window behaves as if you hit those buttons in the window that has the playing tracks. I'm looking into a fix for this now. Was ControlToolbar.cpp over-hauled since the 1.2.6 release? By looking at it for the past 30 minutes or so, it would seem that a lot of these protections would have taken place in here...
- zachelko: Submitted patch to mailing list 3/19/2009 to address Play/Pause/Stop spanning across all open windows. Timeline issue still exists.
|
| P3
|
Calculation of "disk space remains for recording (time)" incorrect when recording in 24 bit quality. Macro now created by RA to return size on disk of 16/24/32 bit sample formats as 2, 3, 4 respectively as first part of a fix, but Audacity does not currently record in 24 bit.
|
| P3
|
Tag import/export occasionally non-orthogonal. Some known specifics:
- GA: ID3v2 Comments tag not seen by Windows Explorer or Windows Media Player 10 on Windows XP SP2
- WAV fields only seen patchily by other apps. as their support is patchy, but Genre tag consistently not seen.
- GA/LL: Although it's a valid WAV info tag (IGNR), we don't support it because current and next libsndfile doesn't. We could patch libsndfile locally, but may be better to switch to taglib when they next release, as that will have AIFF and WAV support. Also because AIFF is written to an ID3 RIFF chunk, that will support AIFF tags in iTunes as standard instead of the current ad hoc adding on to libidtag.
- GA: OGG metadata seems perfect on Windows except VLC sees no tags at all. How is Linux/Mac? Taglib should improve compatibility with VLC, K3b and Amarok.
- GA: As of 12 Aug 09, Audacity cannot see any of its own FLAC tags in 1.3.9-alpha on Linux. Confirmed by STF.
|
| P3
|
Nyquist implementation: Values appearing in effects text boxes are not always the hard-coded/previously entered values.
- GA: Values seem to be re-computed from the pixel values of the slider as visible on-screen, so the nearest value obtainable by using the slider is presented when re-launching the plug-in, rather than the coded default or last entered value (example: highpass.ny). Compute the value from the text field then set the slider? See this thread
- LL: The first part of the issue "100 becomes 101" will have to be resolved and is happening at the lines mentioned in the report. However, this only occurs on redisplay of the dialog. So, if you enter 100 and click OK (or press ENTER), 100 is what will be used when applying the effect. The second part "1.0 = 0.997" is normal floating point behavior.
|
| P3
|
(Windows only) After a period launching correctly, Audacity opens minimised.
|
| P3
|
(Windows only) LADSPA plug-ins not categorisable despite compiling with USE_LIBLRDF defined and installing RDF data files in Audacity data directory. See this thread
|
| P3
|
(Windows only) The slv2 library needed for LV2 support does not build.
- GA: Is slv2 building on Linux?
- DanH: For me it fails (on Linux) but can be fixed by running libtoolize.
|
| P3
|
(Linux only) JACK issues:
- in 1.3.5 from Ubuntu repository, Audacity crashes as soon as play or record started if JACK device selected in preferences (not tested built from CVS)
- JACK has to be shut down before starting Audacity
- Connections in qjackctl not persistent in Audacity session: they only become visible when playback or recording starts, and close when playback or recording stops. Several Linux applications have this problem, but for example alsaplayer seems to have solved it by changing their code? See this Linux musicians thread and this Forum post
- Recording dropouts - these are grouped together with similar Mac problems as a P4 issue, but they might not be related
- Crashes when recording full duplex?
- Audacity must have same sample rate as JACK (seen in 1.3.4 Ubuntu repository builds)
|
| P3
|
(Linux) Audacity output slider may affect playback meters.
- GA: If Portmixer uses emulated playback volume rather than native, the Audacity output slider will affect the VU playback meters and these may not then reflect the actual volume level of the waveform.
|
| P3
|
(Linux only) Effects and other dialogues do not have focus on opening.
- GA: This is a bug in wxGTK for which there is no current workaround. Click in the dialogue to navigate it and change parameters.
|
| P3
|
(Linux only) After opening a sufficiently long audio file, opening a second file of any size leads to locked GUI/console messages until first file completes play. Reported by Michael Schwendt on Fedora 8 test rpms of Audacity CVS from 11 Jan 08 and Jim Cline on Debian 31 Jan 08.
- Expression 'ret' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 1034
Expression 'AlsaOpen( hostApi, parameters, streamDir, &pcm )' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 1066
- DanH: Confirmed on Arch
- JC: Therefore promoted from P4
|