Difference between revisions of "Release Checklist"

• Items added as Priority P1, P2 or P3 should be added to Known Issues, unless they are absent from the published release that page refers to. When cleared, move the items down to the "Cleared in CVS" section of that page.

• Former "Aim to" items from this page have now been moved to the top of Release checklist not aiming for 1.4. If you claim ownership of any items on Release checklist not aiming for 1.4, please cut them from there and and park them at the bottom of Release Checklist.
• Testers should refer to Watching Brief (now on its own page) for intermittent/not fully understood issues.

• LLL: I believe this to be fixed now...just needs some verification.

• GA: Seems fixed apart from minor polishing, except that the meaning of checking/unchecking the boxes on the Warnings tab is reversed. You get the warning about saving a project if you uncheck the box "Show Warnings/Prompts When saving projects, and if you check "Don't show again" in that warning, this checks the box in Preferences.

• JC: Is it really what we want? E.g click split-new twice, and we get four tracks. Is it not less confusing to leave it greyed out?
• GA: If you turn off select-all-on-none, and with one track on screen, Select All, Split New, Select All and Split New, you also get four tracks, so I think it is what we want. Now, if you have a track selected with no time area selected, nothing on the clipboard and click the Edit menu, all the edit menu is enabled except Paste. But if we click outside the track(s) so that none are selected, we lose ability to click on Split Cut, Trim, Delete, Split Delete, Silence, Join, Disjoin, Duplicate and Find Zero Crossings - yet we could still Cut, Copy and Split (FWIW) and Split New. I think that will be very confusing as it's a halfway house between Select-all-on-none and not. So all Edit menu items, and File > Export Selection to be available even if no tracks are selected and when clicking outside the tracks.
• David B. suggests longer term having two independent preference options for selecting all tracks and selecting all audio to give more control.
• MJS: I suggest (after reviewing the menus):
  • Leave grey:
    • "Export Selection..." - there isn't a selection.
    • "Split Cut" / "Trim" / "Split Delete" / "Split" / "Split New" - they make little sense without a selection.
  • Allow with "select all":
    • "Cut" and "Copy" - to cut/copy the whole lot and paste into another project, maybe?
    • "Delete"
    • "Silence Audio" I note it deletes labels as well (and perhaps shouldn't).
    • "Join" - to join up everything
    • "Detach at Silences" - as above
    • "Duplicate" - as above
    • "Mix and Render" - makes sense
    • "Resample" - makes sense
    • "Remove Tracks" - makes sense
    • All (most?) of the effects.

• GA: To reproduce:
  1. Generate a tone
  2. Click in track, CTRL + B, click, CTRL + B along the track
  3. File > Export Multiple and hit Export
  4. Click Export button but nothing happens

If "Include audio before first label" is checked, the metadata window appears for the "audio before" file, then returns on OK to the Export Multiple dialogue.

In 1.2.6, export multiple with empty labels creates files ".wav", "-2.wav", "-3.wav" (or whatever format) and so on. Maybe that should be followed here (except "-1.wav" for the first automatically generated file might be better).

• LLL: Or would it be better to ask the user to specify a name if it encounters a blank label? Similar to the dialog you get if you have a ":" or "/" in the label.
• GA: It's a good idea, but the case for it is not so clear as it is with illegal characters. I know some users who always export empty labels to save typing and are happy with the autonaming, so would not welcome a large number of prompts. Could the prompt include a checkbox "Always export empty labels automatically" and that is then set in .cfg?
• LLL: If that's the concern, then they should be just as happy with us providing a name for them, like "untitled" or "unnamed" or "empty" or "Automatically Generated Name Because It Was Blank". The empty name causes unnecessary coding hackage to create the "-1" file and on at least OSX, a file beginning with a "." will be hidden and not seen if the user tries to open it.
• GA: Obviously I assumed recreating the 1.2.6 behaviour did not have such problems. The issue is not the name itself, but that user will not want prompts for every track (as happens with the "illegal" prompt) if they prefer to use empty labels. So are you OK with one prompt, they choose what it is (or use our default), then we append a suffix as per "numbering consecutively")?

  Just remembered: the "numbering consecutively" suffix is described as a "prefix" in the Export Multiple dialogue, and a few have been complaining about that misnomer. Some users think it should actually be a prefix but looks as if too much work (?). Either way, I'd like to see the "nn" form as per standard on audio CDs, so we lose the problem with folks who don't have natural number sort. Or, it could be an option, default is "nn".

• LLL: Give it a try. I applied Rupinder's patch to correct this P2 and instead of blank names they'll be called "untitled" and I added a list of files exported on the final status dialog to let the users know what the final names were. See how it feels. It can be easily removed.
• GA: I like it. Since there is no other specific information to help users who have left just one label blank, I wondered if we should replace "untitled" with "empty_label" which makes it clear? I think people would prefer that the second and subsequent files included "empty_label" or "untitled" though. So, "empty_label.wav", "empty_label-2.wav" and so on. Is that easily done? I do think "empty_label-1.wav" for the first file "would" have been better, given we adopt this -1, -2, -3 ... scheme for "numbering consecutively".
• LLL: Not sure if "empty_label" would work if there are other cases when a blank filename were possible. I can't think of any off hand though, so if you can't either, we'll change it to "empty_label". The problem with having "-1" is that it really isn't a counter of the label being exported, it's a counter of what files already exist with the name. But, let me fiddle with it a bit. I think I have a solution.

• GA: To reproduce, create a tone of 22,752072 samples, and use Draw Tool to modify the last sample so you can recognise it. Export as PCM 16-bit WAV, and re-import. The modified last sample will be missing. Now exit and restart and create a tone of 45504144 samples (22752072 * 2), modify the last two samples, export and re-import. The last two modified samples will be missing.

• 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...

• 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.

• 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.

• LL: It's because libid3tag exports Unicode data as big-endian and Explorer/WMP seem to require little-endian. And I don't see a way to coax libid3tag into writing in little-endian format without change the library...which I may just do since it will be short lived due to taglib coming post-1.4.
• GA: Well as an interim fix that would of course make Windows users who only use WMP much happier - but would that then break MP3 export on Mac, or on iTunes on either platform? And how does taglib avoid this issue?
• LL: I've changed it...give it a try. WMP, Explorer and iTunes on Intel Mac sees them just fine. Looks like taglib write little endian tags by default.
• GA: Looks fine to me. Will be cleared unless Forum complainants find a problem with the fix.

• zachelko: How are you getting to the Advanced Mixing Options dialog? I'd like to look into this and submit a patch. Thanks.
• GA: Thanks. Multi-channel export is enabled on the Import / Export tab of Preferences by checking "Use custom mix..." in the "When exporting tracks..." panel.
• zachelko: Submitted patch to mailing list on 3/17/2009

• LLL: The wx class does this on purpose. I've been considering doing our own class to handle history since there's an issue with Unicode characters in filenames on the Mac in regards to the wx history class. There's no easy way to override that class to get around the problem and there's no easy way to stop it from removing the path, so maybe our own class is in order.

• "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.

• 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 (open vs import).
• 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?

• LL: It looks like this has been partially fixed...the track menus now change, but tooltips are still an issue.

• 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.

• 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.

LADSPA plug-ins not categorisable despite compiling with USE_LIBLRDF defined and installing RDF data files in Audacity data directory. See this thread

• GA: Is slv2 building on Linux?
• DanH: For me it fails (on Linux) but can be fixed by running libtoolize.

• DB: Logitech USB desktop microphone gives similar behaviour with independent system and Audacity input sliders, and the Audacity slider applies a gain not reflected in the Recording VU meter
• GA: My experience with USB external sound cards and USB turntables on a number of XP machines shows no replicable problems as described. Needs further verification by others.

• 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)

  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

• RS: Started to fix this bug 04 Apr 2009

• Effect::CountWaveTracks Reported by LL.
• SLV2 libraries Reported by MJS
• Effect Previews Reported by Dawson Written

• BP: Reproduced on 1.3.3 - 10.5.1, PPC iBook G4 on 28 Mar 08, but *not* on Intel Mac
• GA: Should be tested with CVS HEAD and PPC, and escalated to P2 if confirmed?

• JC: Progress: Udo tried smaller blocksize in linux/jack version of this problem and can now fault after 4 mins. Perhaps small blocksize will help us track down the problem on non-Jack set ups too. However, perhaps Udo's progress is only relevant to using Jack and no help to Mac? And this problem does not occur consistently on a given system?

• JC: xlisp functions such as xwrchar, xprint and xopen :OUTPUT seem to be already present and correct. Can't find disabled code. DS hypothesises it is code missing in 'the bridge', whatever that is.
• LL: This isn't an issue. All XLisp and Nyquist functions are now available.

• LL: I don't believe this to be a problem. In the first example, the file will go to whatever the current directory is. The Lisp function (setdir) can be used to discover/change what that is. In the second example, you'd have to use a double backslash "c:\\progr..." to get it work work properly.

• Excessive memory usage
  • LL: This will have to be resolved by adding memory pool tracking to lib-src/libnyquist/nyquist/nyqsrc/falloc.c so it can be freed when needed.
• Inaccurate length generation on first use of the plug-in at the default value offered. Correct duration obtainable by using slider or text box to change the value away from, then back to the default (example: pluck.ny)
  • LL: I'm unable to reproduce this and experimenting shows that it has probably been fixed.
• Other inconsistent length generation issues which vary from time to time/one plug-in to another/one Audacity version to another for no apparent reason.
  • LL: This was probably related to the *WARP* variable not being set consistently and should now be fixed.
• Values of sliders in the Audacity effect 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 launching/re-using 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.

• GA: None of these crashes are reproducible on Windows XP, but retained on "Watching Brief" just in case (it could affect Mac as well?)

• GA: What does this mean exactly? Is it that the project rate is not remembered when recovering as reported on -devel list in May 2007? As at May 08 it is set on Windows.

• Crash reported by SIEGERSTEIN: 'failed in 'src/hostapi/oss/pa_unix_oss.c', line: 1206'
• Mihail's issue: PA19 uses oss; without load/compile oss support in alsa (snd-pcm-oss), Audacity crashes on init PA19.
• GA: Are these still replicable or are they fixed with the PA updates?