Audacity Bug Summary
••• Introduction •••
••• Keywords •••
    Audacity 3.0.3 development began 19th April 2021

Audacity Bugzilla



Bug 2471 - Mix Stereo down to Mono fails if space at start of track.
Mix Stereo down to Mono fails if space at start of track.
Status: RESOLVED FIXED
Product: Audacity
Classification: Unclassified
Component: Application Core
2.4.1
Per OS All
: P1 RepeatableAll
Assigned To: Default Assignee for New Bugs
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2020-06-04 09:12 UTC by Steve Daulton
Modified: 2020-06-06 15:08 UTC (History)
8 users (show)

See Also:
Steps To Reproduce:
1) Add a stereo track 2) Generate a 30 second chirp 3) Time Shift the audio to the right 4) Mix Stereo down to Mono 5) Observe the bug (exact result may be platform dependent - see the bug description)
Release Note:
First Git SHA:
Group: ---
Workaround:
Closed: 2020-06-06 00:00:00
stevethefiddle: Must‑Test‑All‑OS+
stevethefiddle: Regression+
petersampsonaudacity: Test‑OK‑Win+
petersampsonaudacity: Test‑OK‑Mac+
stevethefiddle: Test‑OK‑Lin+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Steve Daulton 2020-06-04 09:12:59 UTC
This was reported on Windows.
I'm seeing different symptoms on Linux from those reported on Windows, but both are clearly wrong.

On Linux:
If a stereo track begins with empty "white space", The Mix Stereo down to Mono command results in an empty track.

This is a regression against Audacity 2.3.3.


On Windows, as described on the forum:
I am using Audacity 2.4.1 in Windows 10. If I have a project containing several stereo tracks, each about 45 minutes (they are from spoken word tapes). When I try to mix stereo to mono, the first track has no problem. But any other track takes at least 5 minutes longer to process, and when it is mixed, the program adds at least an hour, sometimes as much as 8 hours, of silence at the beginning of the track. It does not matter which track I mix first. The further down the project the track is, the more time is added at the beginning, and the longer the mixing takes. This did not happen with earlier versions of Audacity. Is this a bug in Audacity 2.4.1?
Comment 1 Cliff Scott 2020-06-04 09:45:08 UTC
On Mac OS Mojave it results in a blank mono track.
Comment 2 Peter Sampson 2020-06-04 11:14:18 UTC
Testing on W10 and macOS 10.15.5 Catalina with Audacity 2.4.2 815e655

1) If I move the track to the right I get the correct selected length - but all blank 

2) If I shift it left so I have audio before zero the progress dialog goes on and on with no apparent result

Same on both platforms
Comment 3 David Bailes 2020-06-05 09:41:08 UTC
Fixed at:
https://github.com/audacity/audacity/commit/13ec3300a9a74d7f4ca6d1a33deebecbf49a1d18

Someone more familiar with the code may well want to check that this fix is OK.
Comment 4 Peter Sampson 2020-06-05 10:13:31 UTC
(In reply to David Bailes from comment #3)
Tested on W10 and macOS 10.15.5 Catalina

Mow seems fine on both platforms

tested
a) audio shifted rightwards (leading blank)
b) audio shifted leftwards - i.e. aome audio before zero
c) audio starting at T=0

all three use cases on both platforms are fine.


>Someone more familiar with the code may well want to check that this fix is OK.

That, David, is not my bailiwick.  I can only comment on the functionality - and I'm more than happy to see this P1 fixed  :-))
Comment 5 Steve Daulton 2020-06-05 11:00:02 UTC
Works for me.
Left open as David requested code review.
Comment 6 Leland Lucius 2020-06-06 13:50:30 UTC
(In reply to David Bailes from comment #3)
> Fixed at:
> https://github.com/audacity/audacity/commit/
> 13ec3300a9a74d7f4ca6d1a33deebecbf49a1d18
> 
> Someone more familiar with the code may well want to check that this fix is
> OK.

Well, I'm the wrong one to ask since I was the one that broke it, but yes, it does look correct now.
Comment 7 Steve Daulton 2020-06-06 14:00:06 UTC
(In reply to Leland Lucius from comment #6)
Thanks Leland.
Closing as Fixed.
Comment 8 David Bailes 2020-06-06 15:08:03 UTC
(In reply to Leland Lucius from comment #6)
> (In reply to David Bailes from comment #3)
> > Fixed at:
> > https://github.com/audacity/audacity/commit/
> > 13ec3300a9a74d7f4ca6d1a33deebecbf49a1d18
> > 
> > Someone more familiar with the code may well want to check that this fix is
> > OK.
> 
> Well, I'm the wrong one to ask since I was the one that broke it, but yes,
> it does look correct now.

Thanks for checking.