Bugzilla – Bug 821
Track sample format setting is not persistent, leading to mismatched clips
Last modified: 2018-08-20 11:51:24 UTC
Even with the patch for bug 820 applied, this is another procedure for producing a wave track with mismatched sample formats in its clips.
This could be fixed by setting WaveTrack::mFormat at load time according to the first clip. But then sample format changes would fail to persist for empty wave tracks. If even empty wave tracks should retain their settings, then a new attribute should be written for WaveTrack.
Created attachment 544 [details] This includes the fix for bug 820 and fixes bug 821 the second proposed way, adding an attribute.
PX->P2. This is a longstanding bug, but still needs RM to decide on whether we accept it for 2.1.0.
Paul wrote in the steps to reproduce: > New project. Generate some noise. Change format of the track to 16 bit. > Save. Close. Reopen. > Look at the sample format menu for the track and see that it reads 32 bit > float again. I think this bug is a duplicate of bug 820, saying the same thing in another way, so this bug should be closed. As with bug 820, the paste at a different bit depth is autosaved immediately, so the bug title seems a little misleading, perhaps wrongly suggesting that the change occurred after reopening the project. As with bug 820, I think the real issue is the interface. If the user changed Default Format to 16-bit between step 1 and 2, Step 2 fails to reproduce. The only case where the meaning of Track Info is clear to me is when importing a WAV file (as opposed to a compressed file) in an unsaved project! We aren't accepting the bug 820 patch, so by definition we aren't accepting the current patch in this bug either. IMO we need one P4 bug to say that the interface needs enhancing. Perhaps it is legitimate to keep bug 820 open at the moment to recognise there is a debate about sample format policy and join it with a Wiki proposal about that policy. As part of that Wiki proposal we should consider if we should expand everything to 32-bit float (it costs some users disk space, may offend some purists who want to keep bit depth byte-for-byte, but removes repetitive dithering if the track is 16-bit).
No-one has objected to closing this bug as a duplicate of bug 820 as far as I know, so I have done that. *** This bug has been marked as a duplicate of bug 820 ***
I did not think these related but different reports were duplicates when I filed them, and James thought this one merited P2. The non-persistency of the setting could be fixed, while the other problems remain. But this is not new functionality or a regression. Steve pointed out that just what that setting should mean, needs a rethink.
I've dropped the rating from P2->P4 (to match 820). I was rating it P2 really as a matter of caution. At the time I did not want to take full responsibility for releasing with this bug. Gale regards this as same as 820, and therefore closed it. Paul states this is not a regression or a result of new functionality. So I am happy that it is closed, and I'm dropping it from P2->P4 so that it is not reopened (at P2) on my account. If there is an aspect of it that is not covered by 820, and someone therefore wants to reopen it at P4, and clarify the wording of the title, that's fine with me. I think though that the meaning of the track sample format setting needs to be clarified (on wiki) as Steve says.
