Tempo Detection is More Than a Bug #7679
Replies: 6 comments 4 replies
-
|
I hope that my tone doesn't come across extremely harshly. I have been increasingly frustrated with this issue and discovered that it has layers. The best of motivations are intended. I just want to help improve things. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for that detailed feedback! I'll first make a general statement, and then go into some of your points one-by-one. We know that the current "music view" is pretty shoddy. It's a compromise to have this functionality at all – Audacity's UI framework at the moment is massively restrictive and the code is weird in what things are easily possible, and what things are not. We had bugs which broke certain characters only when certain menus are enabled, or which broke button accessibility when they were given a color. There's no question that what we have right now is a half-step that's somewhat confusing. However, this feature, together with some others, allows Audacity to be used for music production. In Audacity 3.0, it's essentially impossible to produce music beyond just recording an instrument. In Audacity 3.7, you can reasonably record, work with samples and loops, mix and master your song. This is a huge upgrade for the people that need that, at the cost of some mild inconvenience for other use cases. In Audacity 4, we'll be introducing proper workspaces. This means that you'll have a music workspace with just very different options to a wave editor workspace. And you'll be able to customize and switch between workspaces easily. |
Beta Was this translation helpful? Give feedback.
-
|
Regarding aggressive beat detection, we make the assumption that you're likely to work with something rhythmic once you are in music view. In that case, not detecting a loop when it is one is a bigger disruption than detecting one when there isn't. Note that the Beat Finder analyzer is a very primitive tool and not what the beat/loop detection is using. @saintmatthieu will have a talk on how the new one works at ADC next week: https://conference.audio.dev/session/2024/an-efficient-open-source-c-loop-classifier-and-tempo-estimator/ |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for addressing my comments. I understand that legacy implementation can heavily restrict how a feature is added and how effective it can be. It sounds like the team is actively working towards a solution where music production is possible in a more seamless fashion. I look forward to Audacity version 4. |
Beta Was this translation helpful? Give feedback.
-
|
I would ask that you make requests without multliple paragraphs of moody, bemoaning preamble. "Can you allow for a way to disable beat detection please" would be more than enough. |
Beta Was this translation helpful? Give feedback.
-
|
As indicated in the multiple paragraphs of moody, bemoaning preamble, my comments started as a request for a way to disable beat detection. Fortunately, I found that someone had already made that request, and a way to hide the effects of beat detection were presented as a solution. The cordial request that you prefer has already been made by someone prior to me, and I found it to be insufficient. In my effort to properly address my concern before burdening the team with a new bug report, I researched the issue and user feedback related to beat detection in Audacity. I found confusion, similar to my own experience. Please hear me out. I filed an "Idea for Feature Request" because this isn't a bug. Instead, it seems that an adjustment needs to be made in the user experience design in order to prevent confusion about the feature. I included background context which was intended to convey the frustration that I and others have felt with Audacity since this feature was included in the release. If it provoked emotion within the maintainers team, it was intentional. I only hope that it can be channeled toward addressing the issues presented to improve the product. I don't believe that complaining is useful to developers. Instead, I have provided accurate, repeatable scenarios that demonstrate the issues highlighted. I identified six separate issues. I also provided potential solutions to prime the pump of ideas for solving them. I must be tainted by the rigorous documentation required in the industries where I have worked, but I decided to err on the side of presenting the entire argument. |
Beta Was this translation helpful? Give feedback.
-
@Tantacrul why is this? IF the request is written in polite way, without things like name calling, ad-personam attacks, and alike, than let it be lenghty if thats whats needed.
Its comparable in length I assume 👍🏻 PS. Sorry for MD. |
Beta Was this translation helpful? Give feedback.
-
|
Is there a way of turning off automatic detection yet? `setting preferences Music Imports to "Do nothing" still does something |
Beta Was this translation helpful? Give feedback.
-
Are you testing the latest master build of V3? We're working on this at the moment. @LWinterberg - do you know the status of this particular issue? @tr3v0rb - can you explain a little more what you mean? What is happening exactly? |
Beta Was this translation helpful? Give feedback.
-
|
Are there any updates on this? I imported a .wav file. I was prompted that beats were detected and it asked if I wanted to enable music view and change the tempo. I clicked "No". Now my .wav is at 52%, and my timeline is stuck showing increments of 200 ms. Edit: I'm using version 3.7.1 and there are no pending updates. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Problem to be solved
Audacity is a fantastic piece of open-source software. I'm excited with the new stewardship and contributions happening with it recently from Muse Group. This is a great thing. Improvements in open-source software are fantastic, and company support of open-source software keeps these projects alive.
I've noticed an effort recently in improving the DAW-like functionalities in Audacity. That is wonderful. Unfortunately, changes seem to be trying to make the application a DAW by default. Audacity is also a scientific tool. As music features are added, I would appreciate that Audacity's usefulness as such a tool not be reduced. Please respect the users of the software by not limiting its current usefulness. Historically, Audacity is not music production software. In fact the current description in the "About Audacity" dialog box is "Audacity the free, open source, cross-platform software for recording and editing sounds." I support adding the music production and functionality of a DAW to Audacity in order to make it better. I implore the maintainers of the software to not reduce its functionality for other uses.
I started to reply to an issue that expressed my concerns. Turning off automatic tempo detection. Looking into the issue and coming up with a solution evolved beyond the initial discussion, so I've created a new issue to capture my thoughts. The design of this feature has been frustrating and could use some improvements. This is more than a bug. It is a request to revisit the UI design. Here are suggestions for improving its integration in Audacity.
My Experience
Since the update of Audacity with the feature that automatically detects beats in my files, I have been continually frustrated. I love that the feature was added, but it has ruined my workflow. I primarily use Audacity for audio analysis and comparison. The beat detection and transition to music view have caused extra work and friction over the past many months. I was frustrated enough today to track down the problem and diagnose what was happening.
The features has aggressively changed the functionality of Audacity in general. I tried out the beat detection once to see what it did. My projects for the last six months have been music projects. I didn't know that this had happened. All I saw was that every time I imported more than one file, it would be stretched or squished to some inconsistent length. This is extremely frustrating when I am looking at sample values individually (as the output of some processing that I've applied to it in my research.)
Audacity has been so severely broken, that I stopped using it. I moved over to a different DAW to do the analyses that I needed to perform. This is an indication of a loss of my trust in Audacity as a tool and the recent developmental efforts.
For some reason, I decided to try to use Audacity again today. It was so frustrating that I have dissected the problem and written this novel as feedback. I am not begrudged, and I believe in open source software. That is why I am writing this novel, in order to help improve a fantastic tool
Breakdown of the Issues
The issues that I have with this feature are as follows:
Automatic Beat Detection
When importing a file or creating a new project from an imported file, a music import dialog appears stating that a tempo of some bpm was detected. It asks if music view should be enabled and the project tempo should be changed.
Selecting "No" and ticking "Don't ask me again" results in a behavior where the project settings where the detected tempo is discarded and the project settings remain unchanged. Is the algorithm still running when a file is imported? Based on the the descriptions in Preferences, the behavior is based on whether Audacity detects the imported file as a music file. The user has no ability to control whether the processing is run during import. I don't work with music files in Audacity. Extra processing during import can extend the duration that an import lasts. Whether new features are opt-in or opt-out, we should have a choice.
Inconsistent Imports
In my discoveries, the beat-detection algorithm isn't consistently detecting the tempo for imported files. In the table below, DT, OF, and WS were not detected to have tempo. After importing DO and switching to "music view", importing these same files results in successful beat detection. The files are adjusted to match the tempo of the project. All four of these files were rendered with the same source data, but processed with different spatialization algorithms. The difference in the waveforms is very small, but the resulting derived tempos are inconsistent. This can be observed in the following image.
There seems to be a threshold of confidence being used to determine whether a tempo exists. It is used to decide when a file has tempo or not. Curiously, that threshold is ignored if the project has a tempo set. Rather than importing the non-tempo files at their actual time scale and matching that time scale to the "Bars and Measures" timeline using the project's tempo, a beat detection is run on a file that was previously determined to not have tempo, and the waveform is adjusted to match the detected beats.
Occasionally, one of the files that was not detected to have tempo is found to have a bpm. Why is there a discrepancy for when the same file is found to have a tempo? I kept testing to find out. It turns out that this is happening when I'm in music view and have an empty project. Based on the method that I choose to view time, an imported file is either detected to have a beat or detected to not have a beat. This is frustratingly confusing when a user is unaware of the implementation details.
The Music Import dialog box requires an empty project. Depending on the order in which the files are imported, the behavior of automatic tempo detection varies. It feels like the intention was to add smart things to make working Audacity easier. I respect that; however, if a user can't predict what will happen when they perform an action, they will stop performing that action.
This is unexpected behavior. The inconsistency is confusing. The following table shows the results of "Music Import" on the four files shown. Again, these files are nearly identical with slight variations in the spectral response, but the results of the beat detection and import varies by nearly double. Additionally, the inconsistency in which the beat is detected is shown by putting parentheses around the tempos that did not have a detected tempo when the timeline was set to minutes and seconds.
Aggressive Beat Detection
As I mentioned previously, when I use Audacity I am not working with music files. Most of the files that I'm working on are ambient recordings, transient events, impulse responses, step responses, and other non-musical audio. The minimum threshold for beat detection must be set extremely low because it finds beats in various colors of noise, percussive crashes, doppler shifted wind sources, and others.
I'm biased because my workflow does not use music files. I'd prefer to turn the feature off completely. But if I was producing music and wanted beat detection, I'd like to have both behaviors without being bombarded by dialog windows or having to manually adjust the imported track after import.
The detection algorithm is greedy and finds a beat whether a musical beat exists or not. This is made more evident in the data shown in the section labeled "Inconsistent Imports". When working in music view, adding a percussive effect is made more burdensome by the automatic processing that occurs after the beat detection. In a transient response, a beat is found and the track is stretched or shrunk to match the discovered beat with the projects tempo. The user is then required to manually reset pitch and speed to normal before starting to adjust and tune the clip to fit the music. This extra step is unnecessary and forced into the workflow the the aggressive detection algorithm. Detecting a beat on a track and matching it to the tempo of the project can be done manually when a producer wants that functionality. It does not need to be automatic.
Edit: Holy smokes! This threshold is already exposed and adjustable. It's just buried in the Beat Finder. Manually running Beat finder shows how rarely a beat is detected and also shows that the tempo changes every 0.1 seconds. Electing to change a project to that "tempo" based on such inconsistent and sparse data is ambitiously optimistic.
Accurate Words Carry Meaning
I acknowledge that because Audacity is open-source and extendable, it can be very difficult to be consistent. However, modules produced and distributed by Audacity have a responsibility to elevate that standard for plugin authors.
First, the Music Import dialog that appears when importing a file that has a tempo detected asks the user if they'd like to switch to "music view" and set the project tempo. This is the first and only time that I have seen that term. There is a "View" menu. I'd expect to find something related to the music view in that menu. It is nonexistent. Oh, wait. There's an option labeled "Timeline", and it can be switched between "Minutes and Seconds" or "Beats and measures". There is no indication that this is the same feature. This is a problem of labels and consistency. It is unclear that the two features are connected in any way.
Next, the term "view" has a well practiced application in software. A view is an arrangement of different tools that present data and interactions to a user. A view does not change a the behavior of the software; instead, it changes the interaction of the user with the software in order to streamline specific tasks. A view is distinct and separate from the term "mode". Modal behavior changes the functionality of specific interactions. A mode could changes the specifications under which a task is executed. It could also change the behavior of user inputs.
For example, an IDE (integrated development environment) in programming can present itself more like a file explorer when managing a project. When debugging the application, breakpoints and watched values can be displayed alongside the current exectution location and source code. I choose the example of an IDE specifically. Having the UI present the tools and information most applicable to debugging does not necessitate that the state of the IDE be actively debugging some software. The Debug view changes the presentation of the tools and source code. It is sometimes advantageous to use a Debug view when not debugging. It provides a different paradigm and tools when interacting with the work.
Once an application is launched an a debugger is attached to an application, the workflow changes drastically. In many IDEs, keybinds are changed, the view is automatically switched to the Debug view, the UI may provide additional interactions and information that is only available when attached to an application state. This is an entirely different mode of operation. The functionality of the UI has changed.
Having a different view of something changes the way that one interacts with it. It's behavior is consistent. When it's is operating in a different mode, a new view does not alter the behavior; rather, the operating mode dictates the behavior. I pedantize this distinction because it separates the presentation of the tool, the view, from the behavior of the tool, the mode of operation.
In audacity, the music view behaves more like a mode. It should be treated as such. There are multiple behaviors tied to the project tempo when using music mode that are different when not in music mode. The mode is controlled by the state of a display widget, the timeline. This is backwards. The state of the display widgets should be able to change to reflect the operational mode. I realize that the distinction is subtle and the implementation could be identical; however, the design decisions change drastically with this alteration of paradigm. If Audacity needs a music mode, let's have a music mode, but let it be intentional and obvious. It should also not be a detriment to the other modes of operation (nonmusic modes).
Unintuitive settings
Beat detection and beat matching of imports is not a function of the timeline from a user perspective. The timeline is a view widget. It is a ruler that provides context to where in time events occur. Changing the timeline from "Minutes and Seconds" to "Beats and Measures" changes the units of the ruler. It is an alternate context in which I can view the information in my tracks. It should not change the behavior of importing a track. That is a different modality that has larger scope than a timeline.
Having the detection and stretching of imported music files dependent on the state of the timeline view is backwards. The view should reflect the state of the project not dictate behavior of the application.
As introduced to the music import feature, a user would call the feature "music view" as it is presented in the dialog. It is difficult to predict that in order to restore legacy functionality a user needs to change the timeline view to "Minutes and Seconds".
Selection Scope and Persistent Consequences
I have "Do nothing" chosen under Preferences: Import / Export > Music Imports. Having read this ticket, it still took me 30 minutes to figure out how to disable the beat detection and automatic stretching/shrinking of my audio files when importing them into a project. At one time, I used the music import feature. My project tempo was set appropriately, and the timeline switched to "Bars and Measures". As the project tempo is arbitrary in my work, I didn't worry about processing the imported track. Because beats and tempo shouldn't affect my work, I also clicked "Don't ask me again," so that I would not be bothered by a pop-up every time I imported a track. This was my downfall.
The Music Import dialog box has two decisions for users. First, the user decides whether or not to be prompted with this dialog box again by ticking or leaving unticked the option "Don't ask me again". Second, the user decides whether to set the project tempo to that detect in the file and to switch to music view. This dialog box is subtlely biased and deceptive.
The deception lies in the question, "Would you like to enable music view and set the project tempo to XXX.XX?" Keep in mind that I don't think that this deception was intentionally designed, but rather that it is simply an unintended consequence of marketing a new feature while simplifying the user interaction. There are two questions conjucted together with the option of a single response. The second of the two questions limits the scope of the response to the current project. The first question does not qualify its scope, therby inheriting the scope of the second question. Herein is the deception: the application of the user's decision is not limited to the active project. It is persistent for all future projects. A newly created project inherits the tempo from the previous, and the timeline setting persists as well. There is not default template that acts as a blank canvas. Every new project is a continuation of the project prior.
This behavior was unexpected to me. I anticipated that my decision was bound to the scope of my active project. I don't think that this should be fixed by changing the words of the dialog box. There is a bigger problem here, and it is likely not limited to the timeline and the project tempo.
With the deception identified, let the bias be illuminated. The automatic scanning of imported files for tempo classifies the import as music. This prompts the dialog box which with an affirmative response changes the modality of Audacity to assume that all tracks have tempo and that the track should be matched to the tempo of the project. Files, which if imported first would not be detected to have a tempo, are imported with the best detected tempo and adjusted to match the project. When not operating in music mode, a detected music import will prompt the transition to music mode. When operating in music mode, importing a file which would not be detected as music does not prompt a transition away from music mode. Worse, the import is forced unnaturally into the box of being a beat-driven track.
Combining the unidirectional push towards music view, the persistent nature of a user's decision to use music view, and obfuscated settings preventing a return to historical functionality demonstrates the bias towards music production. I sincerely hope that this is an unintentional side-effect of an infantile feature, and it is not an indication of a push away from members of the community that are not producing music.
Your idea
Suggestions to Fix the Issues
Several issues are expressed in this report, but without a proposal of improvement, it is just a complaint. I hope that stating the issues which I have found will promote a discussion for how to improve this feature and future designs. Here are some suggestions that specifically address to resolve my concerns. Many of the more general suggestions are likely already in place. This is my first interaction with the developer community of Audacity, and I have not read the applicable policies and best practices. For that I apologize and hope it provides context when I have overlooked something.
Opt-out of Automatic
Being plagued with the unexpected behavior of Audacity when importing files, I first search for a way to disable automatic beat detection. I was not alone in my query as I discovered many threads and requests for a similar solution. Adding a binary checkbox to Preferences: Import/Export > Music Import is one possible solution.
[ ] Automatically scan imported files to detect music
In general automatic decisions for creative works should be discouraged. If needed create templates for project that carry the assumptions for the work, but do not apply those assumptions unilaterally across a piece of software that is used in a large variety of applications.
Revisit the Settings and Preferences
As tools become more complex, their capabilities become more diverse. With the addition of operational modality, it becomes more necessary to provide a method to separate preferences and settings specific to those modes. This idea can be extended further applying directly to projects. Extendability also provides limitless power but it naturally feels separated.
When trying to configure the automatic tempo detection, I found that most of the settings that I needed exist. It has been extremely difficult requiring a day of research to locate them.
I would personally remove this and add a feature that lets your set the project tempo from a selection or track. There are so many combinations of variables to make this work consistently.
Music Mode
Create a modality dedicated to the production of music. Make it explicit and obvious, or don't do it at all. Define the other modes that Audacity already supports and will support as they are discovered and introduced. Define which modes are mutually exclusive and which can function harmoniously together. e.g. music mode and non-music mode could both coexist with a recording mode but not with each other.
Create a default setting for the mode that is used for new projects, and save the active setting for the mode in the project save file.
Regarding automatic tempo detection, the biggest problem is that the settings that control how an imported file is treated is hidden as a timeline setting. Separate presentation from functionality and let the presentation reflect functionality. Don't have presentation drive functionality, reverse it.
Prior art
No response
Additional context
Conclusion
As a user, I have grown continually excited and frustrated with the improvements to Audacity. Of particular note, the push toward music production is intruding upon my workflow with sounds unrelated to music. New features should not restrict existing users. I hope that this proposal has helped to identify existing problems in design, implementation, and presentation. I also hope that maintainers are left with a direction for possible solutions to address these issues and others not yet noticed. With additional refinement, Audacity can be more than the free solution for recording and editing sound; it can be the best solution.
Thanks for coming to my TED talk.
Beta Was this translation helpful? Give feedback.
All reactions