audacity-quality — Quality Assurance: priorities for overall usability, interface choices, & bugs

[Audacity-quality] Loudness Normalization

[Steve F. <ste...@gm...>]

I was using Loudness Normalization (built-in effect) a few minutes
ago, and it was repeatedly failing to do anything. No error message
and no effect.

While trying to isolate the problem to reproducible steps, it suddenly
started working correctly. Now, I can't reproduce the problem.

I have extremely high confidence that it was NOT due to user error.

Has anyone else seen this issue?

Steve

[Audacity-quality] New icon size of Transport Toolbar

[Cliff <fly...@gm...>]

The last two builds of Audacity 3.0.3 I’ve done show icons in the transport toolbar that are much larger than they were so it requires a  reset of the tool bars to get the whole toolbar to display. Is that change intended?

Cliff

Re: [Audacity-quality] Updated play at speed

[James C. <jam...@gm...>]

The updated play at speed includes loop play.
In my proposal, loop play 'joins' the start and end of the audio seamlessly.
There will usually be a discontinuity.  That discontinuity needs 'healing'.

By the way, I think a similar mechanism could take the place of snap to
zero crossings, which is a feature to avoid clicks at joins.  Snap to zero
crossings does not work for stereo, as the two channels will have zero
crossings in different places.  But automatically healing any join (if a
user so desires that) could work nicely.

On Thu, 13 May 2021 at 11:11, David Bailes <drb...@gm...> wrote:

> On Thu, 13 May 2021 at 11:07, David Bailes <drb...@gm...> wrote:
>
>> On Thu, 13 May 2021 at 10:52, James Crook <jam...@gm...>
>> wrote:
>>
>>> Thanks for the alert David, and the fix.
>>>
>>> As an aside: I don't regard that as 'my code'.  It dates back to Shane
>>> Mueller, and later (I think) heavily modified / re-written by Paul.  I'd
>>> say "The code" rather than "Your code" especially when talking about a
>>> problem with it 🙂.  I may indeed be responsible for that bug all the same,
>>> though.
>>>
>>
>> I don't think that you were responsible for the bug.
>>
>>
>>>
>>> One detail of the updated play-at-speed is how to heal the audio at the
>>> join.  The repair effect we have is excellent but slow, and would have
>>> trouble keeping up with a changing selection for the loop.....
>>>
>>
>> by "at the join", do you mean the point in the audio where the playback
>> changes direction?
>>
>
> and in what sense does the audio need healing?
>
> David.
>
>
>>
>> David.
>>
>>
>>> --James.
>>>
>>>
>>> On Thu, 13 May 2021 at 09:55, David Bailes <drb...@gm...> wrote:
>>>
>>>> Hi James,
>>>> concerning your possible update, I just wanted to highlight a change I
>>>> made to your play at speed code, because it won't be valid for negative
>>>> speeds. I made a change which fixed a problem with the audio briefly
>>>> dropping out after about 50ms:
>>>> commit: 6b9c8e79cc2da0ca6bf63b13a2519b75ce2dd891
>>>>
>>>> In that commit I assumed that play at speed wasn't negative, which was
>>>> the case at that time.
>>>>
>>>> (I made a further commit: 64079c3f55e0bbee96c96b023ffafc1a64135e99,
>>>> which allowed keyboard scrubbing to change direction without stopping and
>>>> starting again.)
>>>>
>>>> David.
>>>> _______________________________________________
>>>> Audacity-quality mailing list
>>>> Aud...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>>
>>> _______________________________________________
>>> Audacity-quality mailing list
>>> Aud...@li...
>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>
>> _______________________________________________
> Audacity-quality mailing list
> Aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

Re: [Audacity-quality] Updated play at speed

[David B. <drb...@gm...>]

On Thu, 13 May 2021 at 11:07, David Bailes <drb...@gm...> wrote:

> On Thu, 13 May 2021 at 10:52, James Crook <jam...@gm...> wrote:
>
>> Thanks for the alert David, and the fix.
>>
>> As an aside: I don't regard that as 'my code'.  It dates back to Shane
>> Mueller, and later (I think) heavily modified / re-written by Paul.  I'd
>> say "The code" rather than "Your code" especially when talking about a
>> problem with it 🙂.  I may indeed be responsible for that bug all the same,
>> though.
>>
>
> I don't think that you were responsible for the bug.
>
>
>>
>> One detail of the updated play-at-speed is how to heal the audio at the
>> join.  The repair effect we have is excellent but slow, and would have
>> trouble keeping up with a changing selection for the loop.....
>>
>
> by "at the join", do you mean the point in the audio where the playback
> changes direction?
>

and in what sense does the audio need healing?

David.


>
> David.
>
>
>> --James.
>>
>>
>> On Thu, 13 May 2021 at 09:55, David Bailes <drb...@gm...> wrote:
>>
>>> Hi James,
>>> concerning your possible update, I just wanted to highlight a change I
>>> made to your play at speed code, because it won't be valid for negative
>>> speeds. I made a change which fixed a problem with the audio briefly
>>> dropping out after about 50ms:
>>> commit: 6b9c8e79cc2da0ca6bf63b13a2519b75ce2dd891
>>>
>>> In that commit I assumed that play at speed wasn't negative, which was
>>> the case at that time.
>>>
>>> (I made a further commit: 64079c3f55e0bbee96c96b023ffafc1a64135e99,
>>> which allowed keyboard scrubbing to change direction without stopping and
>>> starting again.)
>>>
>>> David.
>>> _______________________________________________
>>> Audacity-quality mailing list
>>> Aud...@li...
>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>
>> _______________________________________________
>> Audacity-quality mailing list
>> Aud...@li...
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>

Re: [Audacity-quality] Updated play at speed

[David B. <drb...@gm...>]

On Thu, 13 May 2021 at 10:52, James Crook <jam...@gm...> wrote:

> Thanks for the alert David, and the fix.
>
> As an aside: I don't regard that as 'my code'.  It dates back to Shane
> Mueller, and later (I think) heavily modified / re-written by Paul.  I'd
> say "The code" rather than "Your code" especially when talking about a
> problem with it 🙂.  I may indeed be responsible for that bug all the same,
> though.
>

I don't think that you were responsible for the bug.


>
> One detail of the updated play-at-speed is how to heal the audio at the
> join.  The repair effect we have is excellent but slow, and would have
> trouble keeping up with a changing selection for the loop.....
>

by "at the join", do you mean the point in the audio where the playback
changes direction?

David.


> --James.
>
>
> On Thu, 13 May 2021 at 09:55, David Bailes <drb...@gm...> wrote:
>
>> Hi James,
>> concerning your possible update, I just wanted to highlight a change I
>> made to your play at speed code, because it won't be valid for negative
>> speeds. I made a change which fixed a problem with the audio briefly
>> dropping out after about 50ms:
>> commit: 6b9c8e79cc2da0ca6bf63b13a2519b75ce2dd891
>>
>> In that commit I assumed that play at speed wasn't negative, which was
>> the case at that time.
>>
>> (I made a further commit: 64079c3f55e0bbee96c96b023ffafc1a64135e99, which
>> allowed keyboard scrubbing to change direction without stopping and
>> starting again.)
>>
>> David.
>> _______________________________________________
>> Audacity-quality mailing list
>> Aud...@li...
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
> _______________________________________________
> Audacity-quality mailing list
> Aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

Re: [Audacity-quality] Updated play at speed

[James C. <jam...@gm...>]

Thanks for the alert David, and the fix.

As an aside: I don't regard that as 'my code'.  It dates back to Shane
Mueller, and later (I think) heavily modified / re-written by Paul.  I'd
say "The code" rather than "Your code" especially when talking about a
problem with it 🙂.  I may indeed be responsible for that bug all the same,
though.

One detail of the updated play-at-speed is how to heal the audio at the
join.  The repair effect we have is excellent but slow, and would have
trouble keeping up with a changing selection for the loop.....

--James.


On Thu, 13 May 2021 at 09:55, David Bailes <drb...@gm...> wrote:

> Hi James,
> concerning your possible update, I just wanted to highlight a change I
> made to your play at speed code, because it won't be valid for negative
> speeds. I made a change which fixed a problem with the audio briefly
> dropping out after about 50ms:
> commit: 6b9c8e79cc2da0ca6bf63b13a2519b75ce2dd891
>
> In that commit I assumed that play at speed wasn't negative, which was the
> case at that time.
>
> (I made a further commit: 64079c3f55e0bbee96c96b023ffafc1a64135e99, which
> allowed keyboard scrubbing to change direction without stopping and
> starting again.)
>
> David.
> _______________________________________________
> Audacity-quality mailing list
> Aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

[Audacity-quality] Updated play at speed

[David B. <drb...@gm...>]

Hi James,
concerning your possible update, I just wanted to highlight a change I made
to your play at speed code, because it won't be valid for negative speeds.
I made a change which fixed a problem with the audio briefly dropping out
after about 50ms:
commit: 6b9c8e79cc2da0ca6bf63b13a2519b75ce2dd891

In that commit I assumed that play at speed wasn't negative, which was the
case at that time.

(I made a further commit: 64079c3f55e0bbee96c96b023ffafc1a64135e99, which
allowed keyboard scrubbing to change direction without stopping and
starting again.)

David.

Re: [Audacity-quality] FFmpeg upgrade has been merged

[Peter S. <pet...@gm...>]

On Wed, May 5, 2021 at 5:05 PM Leland <ll...@ho...> wrote:

> This will bring support up to FFmpeg v4.3.1.
>


> You should still be able to use your existing FFmpeg libs and that should
> be tested.
>

My testing on W10 indicates that this is not the case - see
*Bug 2775* <https://bugzilla.audacityteam.org/show_bug.cgi?id=2775> - Audacity
can crash when exporting some FFmpeg types (when FFmpeg library not updated)
*Bug 2776* <https://bugzilla.audacityteam.org/show_bug.cgi?id=2776> - Wrong
unhelpful error message when importing FFmpeg audio files


But, you can upgrade to any version between our current one and 4.3.1.
> Buanzo doesn’t have the new ones yet, but if you’d like to try the 4.3.1
> version built specifically for Audacity, you can get them from the pull
> request (see below).  Alternatively, you should now be able to use any
> prebuilt version from the ffmpeg.org website.
>
>
>
> https://github.com/audacity/audacity/pull/741
>
> FFmpeg_v4.3.1_for_Audacity_on_Windows_32bit.exe.zip
> <https://github.com/audacity/audacity/files/5941948/FFmpeg_v4.3.1_for_Audacity_on_Windows_32bit.exe.zip>
> FFmpeg_v4.3.1_for_Audacity_on_Windows_32bit.zip
> <https://github.com/audacity/audacity/files/5941949/FFmpeg_v4.3.1_for_Audacity_on_Windows_32bit.zip>
> FFmpeg_v4.3.1_for_Audacity_on_Windows_64bit.exe.zip
> <https://github.com/audacity/audacity/files/5941952/FFmpeg_v4.3.1_for_Audacity_on_Windows_64bit.exe.zip>
> FFmpeg_v4.3.1_for_Audacity_on_Windows_64bit.zip
> <https://github.com/audacity/audacity/files/5941959/FFmpeg_v4.3.1_for_Audacity_on_Windows_64bit.zip>
> FFmpeg_v4.3.1_for_Audacity_on_Windows_Build.zip
> <https://github.com/audacity/audacity/files/5941960/FFmpeg_v4.3.1_for_Audacity_on_Windows_Build.zip>
>
> FFmpeg_v4.3.1_for_Audacity_on_OSX.dmg.zip
> <https://github.com/audacity/audacity/files/5941942/FFmpeg_v4.3.1_for_Audacity_on_OSX.dmg.zip>
> FFmpeg_v4.3.1_for_Audacity_on_OSX.pkg.zip
> <https://github.com/audacity/audacity/files/5941943/FFmpeg_v4.3.1_for_Audacity_on_OSX.pkg.zip>
> FFmpeg_v4.3.1_for_Audacity_on_OSX.zip
> <https://github.com/audacity/audacity/files/5941945/FFmpeg_v4.3.1_for_Audacity_on_OSX.zip>
> FFmpeg_v4.3.1_for_Audacity_on_OSX_Build.zip
> <https://github.com/audacity/audacity/files/5941947/FFmpeg_v4.3.1_for_Audacity_on_OSX_Build.zip>
>
I'm not sure I want to upgrade my FFmpeg - what advantage would I get over
our current library?
I don't need Opus import/export on Mac.

Even if I did want to upgrade I haven;t the foggiest idea what I'd do with
any of the above  😵

which I'd need for 32-bit Audacity on a 64-bit W10 PC   🤔

Peter.

:

>
> _______________________________________________
> Audacity-quality mailing list
> Aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

[Audacity-quality] Installed modules in Linux

[Leland <ll...@ho...>]

I've just committed a fix that changes the install location for "modules" on
Linux.  Prior to the change they would get installed into
/<prefix>/share/audacity/modules.  After the fix they will get installed
into /<prefix>/<libdir>/audacity/modules.

 

For example, before:

 

/usr/local/share/audacity/modules/

 

After:

 

/usr/local/lib64/audacity/modules

 

[Audacity-quality] FFmpeg upgrade has been merged

[Leland <ll...@ho...>]

This will bring support up to FFmpeg v4.3.1.  You should still be able to
use your existing FFmpeg libs and that should be tested.  But, you can
upgrade to any version between our current one and 4.3.1.  Buanzo doesn't
have the new ones yet, but if you'd like to try the 4.3.1 version built
specifically for Audacity, you can get them from the pull request (see
below).  Alternatively, you should now be able to use any prebuilt version
from the ffmpeg.org website.

 

https://github.com/audacity/audacity/pull/741

FFmpeg_v4.3.1_for_Audacity_on_Windows_32bit.exe.zip
<https://github.com/audacity/audacity/files/5941948/FFmpeg_v4.3.1_for_Audaci
ty_on_Windows_32bit.exe.zip> 
FFmpeg_v4.3.1_for_Audacity_on_Windows_32bit.zip
<https://github.com/audacity/audacity/files/5941949/FFmpeg_v4.3.1_for_Audaci
ty_on_Windows_32bit.zip> 
FFmpeg_v4.3.1_for_Audacity_on_Windows_64bit.exe.zip
<https://github.com/audacity/audacity/files/5941952/FFmpeg_v4.3.1_for_Audaci
ty_on_Windows_64bit.exe.zip> 
FFmpeg_v4.3.1_for_Audacity_on_Windows_64bit.zip
<https://github.com/audacity/audacity/files/5941959/FFmpeg_v4.3.1_for_Audaci
ty_on_Windows_64bit.zip> 
FFmpeg_v4.3.1_for_Audacity_on_Windows_Build.zip
<https://github.com/audacity/audacity/files/5941960/FFmpeg_v4.3.1_for_Audaci
ty_on_Windows_Build.zip> 

FFmpeg_v4.3.1_for_Audacity_on_OSX.dmg.zip
<https://github.com/audacity/audacity/files/5941942/FFmpeg_v4.3.1_for_Audaci
ty_on_OSX.dmg.zip> 
FFmpeg_v4.3.1_for_Audacity_on_OSX.pkg.zip
<https://github.com/audacity/audacity/files/5941943/FFmpeg_v4.3.1_for_Audaci
ty_on_OSX.pkg.zip> 
FFmpeg_v4.3.1_for_Audacity_on_OSX.zip
<https://github.com/audacity/audacity/files/5941945/FFmpeg_v4.3.1_for_Audaci
ty_on_OSX.zip> 
FFmpeg_v4.3.1_for_Audacity_on_OSX_Build.zip
<https://github.com/audacity/audacity/files/5941947/FFmpeg_v4.3.1_for_Audaci
ty_on_OSX_Build.zip> 

 

[Audacity-quality] Alexandre Prokoudine's report on Muse and Audacity

[David B. <drb...@gm...>]

Thought this might be of interest to those who haven't already read it:
https://librearts.org/2021/05/ultimate-guitar-launches-muse-group-and-acquires-audacity/

David.

Re: [Audacity-quality] White-box testing of macro programming, many issues opened

[Steve F. <ste...@gm...>]

On Thu, 29 Apr 2021 at 13:02, Paul Licameli <pau...@gm...> wrote:

> Here are some more ideas for fixes.
>
> The scriptables will be fixed individually.  Otherwise Nyquist, script
> pipe, and macros need to share implementation at a higher level than now.
> Make a ScriptExecutor class handling the state.
>
> Steve tells me script pipe users have found Undo useful.  So I will find a
> way to keep it.
>
> Each command must be classified as suitable for inclusion in an undo item
> or not.  Undo, Redo, changes of preferences, are among those that are not.
>
> The script executor accumulates the items it can into an undo item,
> appending them as one.  All return statuses from commands are checked, and
> if any one undoable command fails, all changes are rolled back and the undo
> item is removed.  Nested undo items made by certain commands are merged and
> only one item remains.
>
> Before the executor performs an action not suitable for undo, it stops
> accumulating.  For the next suitable command, it resumes.  This will allow
> Undo usage with script pipe.  However it does change behavior so that where
> before a succession of Undos were used, only one should be used for the
> same result.
>
> Or alternatively, script pipe might simply not merge items, unlike Nyquist
> or macros.  Still I want more precautions and error checks that are lacking
> now.
>

I think that script pipe should not merge items. Try using pipeclient.py
from it's command line interface and I think you will see why.
However, note that script pipe may run a macro, and that macro should merge
items that are within the macro.

Steve


>
> The script pipe has a problem the other paths do not:  alternation of
> script commands and interactive commands is possible, though they are
> serialized in the main thread and never simultaneously.  By listening to
> events emitted by the Undo manager, the script executor can know when to
> stop accumulating because some user action intervened.
>
> PRL
>
> On Thursday, April 29, 2021, Paul Licameli <pau...@gm...>
> wrote:
>
>>
>> Today I've given the macro programming features in Audacity, which I had
>> been unfamiliar with, some white-box testing.  I found many worrying
>> unsafeties.
>>
>> I think a lot of quality improvement work and redesign must go into them,
>> more than is consistent with a short release in May, to fix them
>> comprehensively.  Maybe quick fixes for only the worst things can be done
>> soon.  Maybe we ignore them as only affecting power users.
>>
>> There are four ways that flow of control can enter commands through the
>> scripting system (instead of by the usual keystrokes or menu items):
>> 1) Executing a macro.
>> 2) Using aud-do in Nyquist (whether from the prompt window or a .ny file).
>> 3) Certain individual commands bound to items in the Scriptables
>> sub-menus of Extra.  (I think these exist for accessibility?)
>> 4) Using mod-script-pipe and an external process driving it
>>
>> I have not exercised #4 today but it shares much with #2 and so I suspect
>> some of the bugs demonstrable with #2 might also be replicated that way.
>>
>> I opened ten issues in Bugzilla today, ##2759 - 2768.
>>
>> I think we need to be clearer about what macro commands may and may not
>> do.  I think they should be disallowed access to Undo/Redo, if we also wish
>> each macro invocation itself to push just one item on the Undo stack, as
>> when bug 2076 was fixed.  This implies that macros should not be empowered
>> to emulate arbitrary sequences of keystroke or menu item interactions, but
>> that there must be some limitations.
>>
>> We need more consistency about how errors reported by macro commands
>> should be handled (number 1 rolls back the effects of the incomplete macro
>> on the project, though there may be other persistent effects in exported
>> files or preferences;  numbers 2 and 3 just ignore the error codes and keep
>> going).
>>
>> I think path #1 above is the most robust of them, but still things go
>> wrong, still there can be more states pushed onto the history than we
>> intend, still redo states may be destroyed if the user invokes Undo or
>> Redo, and still there is not proper cleanup of the undo history in case any
>> step of the macro fails.
>>
>> This foray was motivated by my efforts to help Roger figure out how to
>> extend Nyquist with more powerful foreign functions that can change the
>> Audacity project in all ways macro commands might, and maybe more.  I think
>> a solution for the unsafety in aud-do would benefit this project too.
>>
>> Do it well enough, and I would even hope to see development of a
>> non-modal read-eval-print "terminal" window for Nyquist -- wouldn't that be
>> great?  But only if we can properly contain all the side effects in ways
>> that we are confident can't corrupt the integrity of the project in memory
>> or its consistency with the database on disk.  Again, that means imposing
>> some limitations.
>>
>> I my write in more technical detail later in another thread about my
>> ideas for interface Lisp with commands more safely.
>>
>> PRL
>>
>>
>>
>>
>> _______________________________________________
> Audacity-quality mailing list
> Aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

Re: [Audacity-quality] White-box testing of macro programming, many issues opened

[Paul L. <pau...@gm...>]

Here are some more ideas for fixes.

The scriptables will be fixed individually.  Otherwise Nyquist, script
pipe, and macros need to share implementation at a higher level than now.
Make a ScriptExecutor class handling the state.

Steve tells me script pipe users have found Undo useful.  So I will find a
way to keep it.

Each command must be classified as suitable for inclusion in an undo item
or not.  Undo, Redo, changes of preferences, are among those that are not.

The script executor accumulates the items it can into an undo item,
appending them as one.  All return statuses from commands are checked, and
if any one undoable command fails, all changes are rolled back and the undo
item is removed.  Nested undo items made by certain commands are merged and
only one item remains.

Before the executor performs an action not suitable for undo, it stops
accumulating.  For the next suitable command, it resumes.  This will allow
Undo usage with script pipe.  However it does change behavior so that where
before a succession of Undos were used, only one should be used for the
same result.

Or alternatively, script pipe might simply not merge items, unlike Nyquist
or macros.  Still I want more precautions and error checks that are lacking
now.

The script pipe has a problem the other paths do not:  alternation of
script commands and interactive commands is possible, though they are
serialized in the main thread and never simultaneously.  By listening to
events emitted by the Undo manager, the script executor can know when to
stop accumulating because some user action intervened.

PRL

On Thursday, April 29, 2021, Paul Licameli <pau...@gm...> wrote:

>
> Today I've given the macro programming features in Audacity, which I had
> been unfamiliar with, some white-box testing.  I found many worrying
> unsafeties.
>
> I think a lot of quality improvement work and redesign must go into them,
> more than is consistent with a short release in May, to fix them
> comprehensively.  Maybe quick fixes for only the worst things can be done
> soon.  Maybe we ignore them as only affecting power users.
>
> There are four ways that flow of control can enter commands through the
> scripting system (instead of by the usual keystrokes or menu items):
> 1) Executing a macro.
> 2) Using aud-do in Nyquist (whether from the prompt window or a .ny file).
> 3) Certain individual commands bound to items in the Scriptables sub-menus
> of Extra.  (I think these exist for accessibility?)
> 4) Using mod-script-pipe and an external process driving it
>
> I have not exercised #4 today but it shares much with #2 and so I suspect
> some of the bugs demonstrable with #2 might also be replicated that way.
>
> I opened ten issues in Bugzilla today, ##2759 - 2768.
>
> I think we need to be clearer about what macro commands may and may not
> do.  I think they should be disallowed access to Undo/Redo, if we also wish
> each macro invocation itself to push just one item on the Undo stack, as
> when bug 2076 was fixed.  This implies that macros should not be empowered
> to emulate arbitrary sequences of keystroke or menu item interactions, but
> that there must be some limitations.
>
> We need more consistency about how errors reported by macro commands
> should be handled (number 1 rolls back the effects of the incomplete macro
> on the project, though there may be other persistent effects in exported
> files or preferences;  numbers 2 and 3 just ignore the error codes and keep
> going).
>
> I think path #1 above is the most robust of them, but still things go
> wrong, still there can be more states pushed onto the history than we
> intend, still redo states may be destroyed if the user invokes Undo or
> Redo, and still there is not proper cleanup of the undo history in case any
> step of the macro fails.
>
> This foray was motivated by my efforts to help Roger figure out how to
> extend Nyquist with more powerful foreign functions that can change the
> Audacity project in all ways macro commands might, and maybe more.  I think
> a solution for the unsafety in aud-do would benefit this project too.
>
> Do it well enough, and I would even hope to see development of a non-modal
> read-eval-print "terminal" window for Nyquist -- wouldn't that be great?
> But only if we can properly contain all the side effects in ways that we
> are confident can't corrupt the integrity of the project in memory or its
> consistency with the database on disk.  Again, that means imposing some
> limitations.
>
> I my write in more technical detail later in another thread about my ideas
> for interface Lisp with commands more safely.
>
> PRL
>
>
>
>
>

[Audacity-quality] White-box testing of macro programming, many issues opened

[Paul L. <pau...@gm...>]

Today I've given the macro programming features in Audacity, which I had
been unfamiliar with, some white-box testing.  I found many worrying
unsafeties.

I think a lot of quality improvement work and redesign must go into them,
more than is consistent with a short release in May, to fix them
comprehensively.  Maybe quick fixes for only the worst things can be done
soon.  Maybe we ignore them as only affecting power users.

There are four ways that flow of control can enter commands through the
scripting system (instead of by the usual keystrokes or menu items):
1) Executing a macro.
2) Using aud-do in Nyquist (whether from the prompt window or a .ny file).
3) Certain individual commands bound to items in the Scriptables sub-menus
of Extra.  (I think these exist for accessibility?)
4) Using mod-script-pipe and an external process driving it

I have not exercised #4 today but it shares much with #2 and so I suspect
some of the bugs demonstrable with #2 might also be replicated that way.

I opened ten issues in Bugzilla today, ##2759 - 2768.

I think we need to be clearer about what macro commands may and may not
do.  I think they should be disallowed access to Undo/Redo, if we also wish
each macro invocation itself to push just one item on the Undo stack, as
when bug 2076 was fixed.  This implies that macros should not be empowered
to emulate arbitrary sequences of keystroke or menu item interactions, but
that there must be some limitations.

We need more consistency about how errors reported by macro commands should
be handled (number 1 rolls back the effects of the incomplete macro on the
project, though there may be other persistent effects in exported files or
preferences;  numbers 2 and 3 just ignore the error codes and keep going).

I think path #1 above is the most robust of them, but still things go
wrong, still there can be more states pushed onto the history than we
intend, still redo states may be destroyed if the user invokes Undo or
Redo, and still there is not proper cleanup of the undo history in case any
step of the macro fails.

This foray was motivated by my efforts to help Roger figure out how to
extend Nyquist with more powerful foreign functions that can change the
Audacity project in all ways macro commands might, and maybe more.  I think
a solution for the unsafety in aud-do would benefit this project too.

Do it well enough, and I would even hope to see development of a non-modal
read-eval-print "terminal" window for Nyquist -- wouldn't that be great?
But only if we can properly contain all the side effects in ways that we
are confident can't corrupt the integrity of the project in memory or its
consistency with the database on disk.  Again, that means imposing some
limitations.

I my write in more technical detail later in another thread about my ideas
for interface Lisp with commands more safely.

PRL

Re: [Audacity-quality] Running audacity on Windows subsystem for Linux

[James C. <jam...@gm...>]

Thanks David!

Great to see Audacity as the reference app used to check/demo sound on wsl.

On Thu, 22 Apr 2021 at 21:48, David Bailes <drb...@gm...> wrote:

> just in case this is of interest to anyone:
>
> https://devblogs.microsoft.com/commandline/the-initial-preview-of-gui-app-support-is-now-available-for-the-windows-subsystem-for-linux-2/
>
> David.
> _______________________________________________
> Audacity-quality mailing list
> Aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

[Audacity-quality] Running audacity on Windows subsystem for Linux

[David B. <drb...@gm...>]

just in case this is of interest to anyone:
https://devblogs.microsoft.com/commandline/the-initial-preview-of-gui-app-support-is-now-available-for-the-windows-subsystem-for-linux-2/

David.

Re: [Audacity-quality] 3.0.2 downloads

[James C. <jam...@gm...>]

Thanks David!

I'm glad you find the automated download helpful.

The automated download uses a copy held at GitHub.  GitHub have a
bandwidth limit, but GitHub don't say what the limit is, and we haven't
asked them to clarify.  It is possible the automatic downloads could stop
working because of their bandwidth limit (or more likely they could become
very very slow as/when GitHub impose the traffic limits).  The FossHub
links - which link to the same binaries with the same checksums - will
still be there if that happens.

Possibly it would make more sense if the 'direct links' went to FossHub
too, and only the automated download to GitHub.

--James.


On Tue, 20 Apr 2021 at 10:03, David Bailes <drb...@gm...> wrote:

> On the Windows and Mac download pages, the automatic download is helpful,
> but the pages are a little confusing: the automatic and direct links are
> different from the link in the recommended downloads section.
>
> David.
> _______________________________________________
> Audacity-quality mailing list
> Aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

[Audacity-quality] 3.0.2 downloads

[David B. <drb...@gm...>]

On the Windows and Mac download pages, the automatic download is helpful,
but the pages are a little confusing: the automatic and direct links are
different from the link in the recommended downloads section.

David.

Re: [Audacity-quality] Export Multiple Bug?

[Cliff <fly...@gm...>]

Yes, that looks fine. When I did a search on Bugzilla for Open bugs it did not come up. Search for New was even worse. I guess I don’t understand something about Bugzilla and how to us it.

Cliff

> On Apr 17, 2021, at 15:55, Bill Wharrie <bi...@go...> wrote:
> 
> 
> 
>> On 2021/04/17, at 4:35 PM, Cliff <fly...@gm... <mailto:fly...@gm...>> wrote:
>> 
>> Was this ever posted as a bug? I don’t see one that looks like this.
> 
> Does this not describe the problem?
> 
> https://bugzilla.audacityteam.org/show_bug.cgi?id=2750 <https://bugzilla.audacityteam.org/show_bug.cgi?id=2750>
> 
> — Bill
> 
>> 
>> Cliff
>> 
>>> On Apr 16, 2021, at 02:37, Peter Sampson <pet...@gm... <mailto:pet...@gm...>> wrote:
>>> 
>>> 
>>> 
>>> On Fri, Apr 16, 2021 at 1:20 AM Bill Wharrie <bi...@go... <mailto:bi...@go...>> wrote:
>>> Could folks test this when you get a chance?
>>> 
>>> I’m not suggesting we hold up 3.0.2 for this (since it goes back to 2.4.0 and Cliff seems the first to notice) so there’s no panic to test it soon. I’d just like to confirm with others what I’m seeing and confirm the steps before I open a bug. Thanks.
>>> 
>>> I think there's no chance of this holding up 3.0.2 - as the potential fix for
>>> moonphase 2700 is far more serious.
>>> 
>>> Please log this Bug Bill.
>>> 
>>> Peter.
>>> 
>>> 
>>> 
>>> 
>>> Steps to reproduce
>>> 
>>> With any Audacity (2.4.0 or later; I can’t test earlier), with a new empty project:
>>> 
>>> 1) Open the metadata editor
>>> 2) Enter some easily-identifiable info in the fields, such as “The Track Title”, “The Artist”, “The Album Name”, “The Genre”, “The Comment”. Maybe “99” for the Track Number and “2030” for the Year.
>>> 3) Click “Set Default” and close the metadata editor
>>> 4) Import or create some audio
>>> 5) Enter a few labels in preparation for Export Multiple
>>> 6) Open the metadata editor and enter new information in all the fields, or just clear some (such as Year or Genre); make sure to enter something different from the defaults.
>>> 7) Do Export Multiple as MP3
>>> 8) Import one of the exported files into a new project
>>> 9) Open the metadata editor
>>> Note:
>>> The Track Name and Track Number have been filled in properly by the Export Multiple command
>>> All other metadata fields have been filled in from the “defaults” (steps 2 and 3) rather than what was entered in step 6.
>>> 
>>> The workaround is to clear all the metadata fields then click “Set Defaults”.
>>> 
>>> 
>>> 
>>> 
>>> — Bill
>>> 
>>>> On 2021/04/15, at 7:55 PM, Bill Wharrie <bi...@go... <mailto:bi...@go...>> wrote:
>>>> 
>>>> 
>>>> 
>>>>> On 2021/04/15, at 7:47 PM, Bill Wharrie <bi...@go... <mailto:bi...@go...>> wrote:
>>>>> 
>>>>> Cliff:
>>>>> OK, I see it now. IMO this is a bug. I’m not sure yet if it is a regression.
>>>> 
>>>> This wrong behaviour goes back to 2.4.0. I can’t test earlier.
>>>> — Bill
>>>>> 
>>>>> The workaround is like this:
>>>>> - open the metadata editor
>>>>> - clear all the fields
>>>>> - click “Set Default”
>>>>> This sets the default to all fields empty. Now Audacity will fill in the metadata for each exported file correctly.
>>>>> 
>>>>> So you’re right: Audacity is using its “default” metadata to over-ride what the user enters.
>>>>> 
>>>>> — Bill
>>>>> 
>>>>> PS: this is what I got:
>>>>> Defaults:
>>>>> 
>>>>> <Defaults.png>
>>>>> 
>>>>> What I entered before I did Export Multiple:
>>>>> <WhatIWant.png>
>>>>> 
>>>>> 
>>>>> What I got:
>>>>> <WhatIGet.png>
>>>>> 
>>>>>> On 2021/04/15, at 5:45 PM, Cliff <fly...@gm... <mailto:fly...@gm...>> wrote:
>>>>>> 
>>>>>> Hi Bill,
>>>>>> 
>>>>>> I expect to have Track Title and Track Number set in the course of the Export Multiple. I’m speaking of other fields as you will see below:
>>>>>> 
>>>>>> This is  what I set in the project:
>>>>>> 
>>>>>> <PastedGraphic-3.png>
>>>>>> 
>>>>>> This is the default:
>>>>>> 
>>>>>> <PastedGraphic-5.png>
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>  This is what I get for the first export of 52:
>>>>>> 
>>>>>> <PastedGraphic-4.png>
>>>>>> 
>>>>>> Note that the metadata I set has Artist set to Children and Genre set as Vocal, but when export multiple is used then I get John Greene as Artist and Sermon as the Genre. The default is overriding the user set value. This should NOT be as I understand it.
>>>>>> 
>>>>>> The only way I found around it is to set the one I wanted as default then when done revert back to the normal default.
>>>>>> 
>>>>>> Cliff
>>>>>>> On Apr 15, 2021, at 16:03, Bill Wharrie <bi...@go... <mailto:bi...@go...>> wrote:
>>>>>>> 
>>>>>>> My understanding of the behaviour of Export Multiple is that it treats the a) Track Title and b) Track Number as special cases. Whether or not they contain data, they are filled with a) the label text, and b) the “label number” counting from the beginning of the export. This was done in support (I imagine) of those who were digitizing their vinyl , etc. They could fill in the common info (Artist Name, Album Title, etc) then Audacity would fill in the Track Title and Track Number for them. Is this what you’re seeing?
>>>>>>> 
>>>>>>>> On 2021/04/15, at 2:37 PM, Cliff <fly...@gm... <mailto:fly...@gm...>> wrote:
>>>>>>>> 
>>>>>>>> I read the manual and it doesn’t address this issue. A normal export works fine where user entered is not overwritten by the default.
>>>>>>>> 
>>>>>>>> Apparently Export Multiple does not follow the same protocol regarding the default metadata overwriting user entered data or filling in data in empty fields during export. The default overwrites those the user set fields in which the default has data. 
>>>>>>> 
>>>>>>> I don’t understand this. What is “default metadata” versus “user entered data”?
>>>>>>> 
>>>>>>> “Default” metadata has a particular meaning in Audacity: the metadata Audacity uses if none is supplied.
>>>>>>> • Set Default: Makes the current list of tag names and non-empty values the default state whenever opening a new, empty project. To clear the default, press Clear then Set Default.
>>>>>>> Even if you set a Default, if you import a file containing metadata, that metadata will appear in Metadata Editor. If you always want a fixed set of metadata to show after importing a file, you need to save that set as a template then load the template after importing the file.
>>>>>>> 
>>>>>>> — Bill
>>>>>>> 
>>>>>>> 
>>>>>>>> Very bad idea. We dealt with this a while back with normal exporting, but apparently what was done didn’t apply to Export Multiple. As it is now it requires the user to first, know that it will do this to what ever he as set in the metadata and secondly he has to set what he wants to be there as default then do the export multiple then go back and put the default back to where it was. The user would not know this happened if he didn’t look at each metadata for each file as it exports. I can’t imagine editing 52 metadata files during export to fix them or uploading files somewhere then finding out the metadata was messed up.
>>>>>>>> 
>>>>>>>> Should I log this as a bug?
>>>>>>>> 
>>>>>>>> Cliff
>>>>>>>> 
>>>>>>>>> On Apr 15, 2021, at 12:36, Peter Sampson <pet...@gm... <mailto:pet...@gm...>> wrote:
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Thu, Apr 15, 2021 at 4:26 PM Cliff <fly...@gm... <mailto:fly...@gm...>> wrote:
>>>>>>>>> I’ve just run into an issue that maybe is my wrong understanding of something, but to me seems like a bug.
>>>>>>>>> 
>>>>>>>>> I’m exporting a file that has 52 labels so I want to get 52 files out of it. Trying to export I find it insists on overwriting the Metadata I have with the default metadata. Even the first file does not have what I set as metadata. Is this a bug or just that I have to reset the default metadata for this export then reinstate it afterwards? I thought we had dealt with this issue a while back, but can’t remember for sure.
>>>>>>>>> 
>>>>>>>>> I don't know what's supposed to happen - that's the problem when you don't 
>>>>>>>>> build from specs.  I'm not sure what the Manual has to say abut it.
>>>>>>>>> 
>>>>>>>>> Does this behavior differ from a normal Export?
>>>>>>>>> 
>>>>>>>>> One thing I do know is that our handling of metadata is and always has been pretty
>>>>>>>>> average at best - there are several outstanding metadata bugs and a proposal IIRC.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Certainly when I was using Export Multiple for my LP transcriptions some years back
>>>>>>>>> I never bothered with metadata in Audacity - I did all tat in iTunes as at the time I was
>>>>>>>>> making files for my iPods.  Then later I did it all again with my hi-fi jukebox gadget
>>>>>>>>> as then I wanted to use lossless WAVs - not that the WAVs carry the metadata, rather
>>>>>>>>> its the database for the jukebox gadget that handles that (and pretty poorly too I might
>>>>>>>>> add).
>>>>>>>>> 
>>>>>>>>> Peter.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Cliff
>>>> 
>>>> _______________________________________________
>>>> Audacity-quality mailing list
>>>> Aud...@li... <mailto:Aud...@li...>
>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality <https://lists.sourceforge.net/lists/listinfo/audacity-quality>
>>> 
>>> _______________________________________________
>>> Audacity-quality mailing list
>>> Aud...@li... <mailto:Aud...@li...>
>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality <https://lists.sourceforge.net/lists/listinfo/audacity-quality>
>>> _______________________________________________
>>> Audacity-quality mailing list
>>> Aud...@li... <mailto:Aud...@li...>
>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality <https://lists.sourceforge.net/lists/listinfo/audacity-quality>
>> 
>> _______________________________________________
>> Audacity-quality mailing list
>> Aud...@li... <mailto:Aud...@li...>
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality <https://lists.sourceforge.net/lists/listinfo/audacity-quality>
> 
> _______________________________________________
> Audacity-quality mailing list
> Aud...@li... <mailto:Aud...@li...>
> https://lists.sourceforge.net/lists/listinfo/audacity-quality <https://lists.sourceforge.net/lists/listinfo/audacity-quality>

Re: [Audacity-quality] Export Multiple Bug?

[Bill W. <bi...@go...>]

> On 2021/04/17, at 4:35 PM, Cliff <fly...@gm...> wrote:
> 
> Was this ever posted as a bug? I don’t see one that looks like this.

Does this not describe the problem?

https://bugzilla.audacityteam.org/show_bug.cgi?id=2750 <https://bugzilla.audacityteam.org/show_bug.cgi?id=2750>

— Bill

> 
> Cliff
> 
>> On Apr 16, 2021, at 02:37, Peter Sampson <pet...@gm... <mailto:pet...@gm...>> wrote:
>> 
>> 
>> 
>> On Fri, Apr 16, 2021 at 1:20 AM Bill Wharrie <bi...@go... <mailto:bi...@go...>> wrote:
>> Could folks test this when you get a chance?
>> 
>> I’m not suggesting we hold up 3.0.2 for this (since it goes back to 2.4.0 and Cliff seems the first to notice) so there’s no panic to test it soon. I’d just like to confirm with others what I’m seeing and confirm the steps before I open a bug. Thanks.
>> 
>> I think there's no chance of this holding up 3.0.2 - as the potential fix for
>> moonphase 2700 is far more serious.
>> 
>> Please log this Bug Bill.
>> 
>> Peter.
>> 
>> 
>> 
>> 
>> Steps to reproduce
>> 
>> With any Audacity (2.4.0 or later; I can’t test earlier), with a new empty project:
>> 
>> 1) Open the metadata editor
>> 2) Enter some easily-identifiable info in the fields, such as “The Track Title”, “The Artist”, “The Album Name”, “The Genre”, “The Comment”. Maybe “99” for the Track Number and “2030” for the Year.
>> 3) Click “Set Default” and close the metadata editor
>> 4) Import or create some audio
>> 5) Enter a few labels in preparation for Export Multiple
>> 6) Open the metadata editor and enter new information in all the fields, or just clear some (such as Year or Genre); make sure to enter something different from the defaults.
>> 7) Do Export Multiple as MP3
>> 8) Import one of the exported files into a new project
>> 9) Open the metadata editor
>> Note:
>> The Track Name and Track Number have been filled in properly by the Export Multiple command
>> All other metadata fields have been filled in from the “defaults” (steps 2 and 3) rather than what was entered in step 6.
>> 
>> The workaround is to clear all the metadata fields then click “Set Defaults”.
>> 
>> 
>> 
>> 
>> — Bill
>> 
>>> On 2021/04/15, at 7:55 PM, Bill Wharrie <bi...@go... <mailto:bi...@go...>> wrote:
>>> 
>>> 
>>> 
>>>> On 2021/04/15, at 7:47 PM, Bill Wharrie <bi...@go... <mailto:bi...@go...>> wrote:
>>>> 
>>>> Cliff:
>>>> OK, I see it now. IMO this is a bug. I’m not sure yet if it is a regression.
>>> 
>>> This wrong behaviour goes back to 2.4.0. I can’t test earlier.
>>> — Bill
>>>> 
>>>> The workaround is like this:
>>>> - open the metadata editor
>>>> - clear all the fields
>>>> - click “Set Default”
>>>> This sets the default to all fields empty. Now Audacity will fill in the metadata for each exported file correctly.
>>>> 
>>>> So you’re right: Audacity is using its “default” metadata to over-ride what the user enters.
>>>> 
>>>> — Bill
>>>> 
>>>> PS: this is what I got:
>>>> Defaults:
>>>> 
>>>> <Defaults.png>
>>>> 
>>>> What I entered before I did Export Multiple:
>>>> <WhatIWant.png>
>>>> 
>>>> 
>>>> What I got:
>>>> <WhatIGet.png>
>>>> 
>>>>> On 2021/04/15, at 5:45 PM, Cliff <fly...@gm... <mailto:fly...@gm...>> wrote:
>>>>> 
>>>>> Hi Bill,
>>>>> 
>>>>> I expect to have Track Title and Track Number set in the course of the Export Multiple. I’m speaking of other fields as you will see below:
>>>>> 
>>>>> This is  what I set in the project:
>>>>> 
>>>>> <PastedGraphic-3.png>
>>>>> 
>>>>> This is the default:
>>>>> 
>>>>> <PastedGraphic-5.png>
>>>>> 
>>>>> 
>>>>> 
>>>>>  This is what I get for the first export of 52:
>>>>> 
>>>>> <PastedGraphic-4.png>
>>>>> 
>>>>> Note that the metadata I set has Artist set to Children and Genre set as Vocal, but when export multiple is used then I get John Greene as Artist and Sermon as the Genre. The default is overriding the user set value. This should NOT be as I understand it.
>>>>> 
>>>>> The only way I found around it is to set the one I wanted as default then when done revert back to the normal default.
>>>>> 
>>>>> Cliff
>>>>>> On Apr 15, 2021, at 16:03, Bill Wharrie <bi...@go... <mailto:bi...@go...>> wrote:
>>>>>> 
>>>>>> My understanding of the behaviour of Export Multiple is that it treats the a) Track Title and b) Track Number as special cases. Whether or not they contain data, they are filled with a) the label text, and b) the “label number” counting from the beginning of the export. This was done in support (I imagine) of those who were digitizing their vinyl , etc. They could fill in the common info (Artist Name, Album Title, etc) then Audacity would fill in the Track Title and Track Number for them. Is this what you’re seeing?
>>>>>> 
>>>>>>> On 2021/04/15, at 2:37 PM, Cliff <fly...@gm... <mailto:fly...@gm...>> wrote:
>>>>>>> 
>>>>>>> I read the manual and it doesn’t address this issue. A normal export works fine where user entered is not overwritten by the default.
>>>>>>> 
>>>>>>> Apparently Export Multiple does not follow the same protocol regarding the default metadata overwriting user entered data or filling in data in empty fields during export. The default overwrites those the user set fields in which the default has data. 
>>>>>> 
>>>>>> I don’t understand this. What is “default metadata” versus “user entered data”?
>>>>>> 
>>>>>> “Default” metadata has a particular meaning in Audacity: the metadata Audacity uses if none is supplied.
>>>>>> • Set Default: Makes the current list of tag names and non-empty values the default state whenever opening a new, empty project. To clear the default, press Clear then Set Default.
>>>>>> Even if you set a Default, if you import a file containing metadata, that metadata will appear in Metadata Editor. If you always want a fixed set of metadata to show after importing a file, you need to save that set as a template then load the template after importing the file.
>>>>>> 
>>>>>> — Bill
>>>>>> 
>>>>>> 
>>>>>>> Very bad idea. We dealt with this a while back with normal exporting, but apparently what was done didn’t apply to Export Multiple. As it is now it requires the user to first, know that it will do this to what ever he as set in the metadata and secondly he has to set what he wants to be there as default then do the export multiple then go back and put the default back to where it was. The user would not know this happened if he didn’t look at each metadata for each file as it exports. I can’t imagine editing 52 metadata files during export to fix them or uploading files somewhere then finding out the metadata was messed up.
>>>>>>> 
>>>>>>> Should I log this as a bug?
>>>>>>> 
>>>>>>> Cliff
>>>>>>> 
>>>>>>>> On Apr 15, 2021, at 12:36, Peter Sampson <pet...@gm... <mailto:pet...@gm...>> wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Thu, Apr 15, 2021 at 4:26 PM Cliff <fly...@gm... <mailto:fly...@gm...>> wrote:
>>>>>>>> I’ve just run into an issue that maybe is my wrong understanding of something, but to me seems like a bug.
>>>>>>>> 
>>>>>>>> I’m exporting a file that has 52 labels so I want to get 52 files out of it. Trying to export I find it insists on overwriting the Metadata I have with the default metadata. Even the first file does not have what I set as metadata. Is this a bug or just that I have to reset the default metadata for this export then reinstate it afterwards? I thought we had dealt with this issue a while back, but can’t remember for sure.
>>>>>>>> 
>>>>>>>> I don't know what's supposed to happen - that's the problem when you don't 
>>>>>>>> build from specs.  I'm not sure what the Manual has to say abut it.
>>>>>>>> 
>>>>>>>> Does this behavior differ from a normal Export?
>>>>>>>> 
>>>>>>>> One thing I do know is that our handling of metadata is and always has been pretty
>>>>>>>> average at best - there are several outstanding metadata bugs and a proposal IIRC.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Certainly when I was using Export Multiple for my LP transcriptions some years back
>>>>>>>> I never bothered with metadata in Audacity - I did all tat in iTunes as at the time I was
>>>>>>>> making files for my iPods.  Then later I did it all again with my hi-fi jukebox gadget
>>>>>>>> as then I wanted to use lossless WAVs - not that the WAVs carry the metadata, rather
>>>>>>>> its the database for the jukebox gadget that handles that (and pretty poorly too I might
>>>>>>>> add).
>>>>>>>> 
>>>>>>>> Peter.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Cliff
>>> 
>>> _______________________________________________
>>> Audacity-quality mailing list
>>> Aud...@li... <mailto:Aud...@li...>
>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality <https://lists.sourceforge.net/lists/listinfo/audacity-quality>
>> 
>> _______________________________________________
>> Audacity-quality mailing list
>> Aud...@li... <mailto:Aud...@li...>
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality <https://lists.sourceforge.net/lists/listinfo/audacity-quality>
>> _______________________________________________
>> Audacity-quality mailing list
>> Aud...@li... <mailto:Aud...@li...>
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
> 
> _______________________________________________
> Audacity-quality mailing list
> Aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

Re: [Audacity-quality] Export Multiple Bug?

[Cliff <fly...@gm...>]

Was this ever posted as a bug? I don’t see one that looks like this.

Cliff

> On Apr 16, 2021, at 02:37, Peter Sampson <pet...@gm...> wrote:
> 
> 
> 
> On Fri, Apr 16, 2021 at 1:20 AM Bill Wharrie <bi...@go... <mailto:bi...@go...>> wrote:
> Could folks test this when you get a chance?
> 
> I’m not suggesting we hold up 3.0.2 for this (since it goes back to 2.4.0 and Cliff seems the first to notice) so there’s no panic to test it soon. I’d just like to confirm with others what I’m seeing and confirm the steps before I open a bug. Thanks.
> 
> I think there's no chance of this holding up 3.0.2 - as the potential fix for
> moonphase 2700 is far more serious.
> 
> Please log this Bug Bill.
> 
> Peter.
> 
> 
> 
> 
> Steps to reproduce
> 
> With any Audacity (2.4.0 or later; I can’t test earlier), with a new empty project:
> 
> 1) Open the metadata editor
> 2) Enter some easily-identifiable info in the fields, such as “The Track Title”, “The Artist”, “The Album Name”, “The Genre”, “The Comment”. Maybe “99” for the Track Number and “2030” for the Year.
> 3) Click “Set Default” and close the metadata editor
> 4) Import or create some audio
> 5) Enter a few labels in preparation for Export Multiple
> 6) Open the metadata editor and enter new information in all the fields, or just clear some (such as Year or Genre); make sure to enter something different from the defaults.
> 7) Do Export Multiple as MP3
> 8) Import one of the exported files into a new project
> 9) Open the metadata editor
> Note:
> The Track Name and Track Number have been filled in properly by the Export Multiple command
> All other metadata fields have been filled in from the “defaults” (steps 2 and 3) rather than what was entered in step 6.
> 
> The workaround is to clear all the metadata fields then click “Set Defaults”.
> 
> 
> 
> 
> — Bill
> 
>> On 2021/04/15, at 7:55 PM, Bill Wharrie <bi...@go... <mailto:bi...@go...>> wrote:
>> 
>> 
>> 
>>> On 2021/04/15, at 7:47 PM, Bill Wharrie <bi...@go... <mailto:bi...@go...>> wrote:
>>> 
>>> Cliff:
>>> OK, I see it now. IMO this is a bug. I’m not sure yet if it is a regression.
>> 
>> This wrong behaviour goes back to 2.4.0. I can’t test earlier.
>> — Bill
>>> 
>>> The workaround is like this:
>>> - open the metadata editor
>>> - clear all the fields
>>> - click “Set Default”
>>> This sets the default to all fields empty. Now Audacity will fill in the metadata for each exported file correctly.
>>> 
>>> So you’re right: Audacity is using its “default” metadata to over-ride what the user enters.
>>> 
>>> — Bill
>>> 
>>> PS: this is what I got:
>>> Defaults:
>>> 
>>> <Defaults.png>
>>> 
>>> What I entered before I did Export Multiple:
>>> <WhatIWant.png>
>>> 
>>> 
>>> What I got:
>>> <WhatIGet.png>
>>> 
>>>> On 2021/04/15, at 5:45 PM, Cliff <fly...@gm... <mailto:fly...@gm...>> wrote:
>>>> 
>>>> Hi Bill,
>>>> 
>>>> I expect to have Track Title and Track Number set in the course of the Export Multiple. I’m speaking of other fields as you will see below:
>>>> 
>>>> This is  what I set in the project:
>>>> 
>>>> <PastedGraphic-3.png>
>>>> 
>>>> This is the default:
>>>> 
>>>> <PastedGraphic-5.png>
>>>> 
>>>> 
>>>> 
>>>>  This is what I get for the first export of 52:
>>>> 
>>>> <PastedGraphic-4.png>
>>>> 
>>>> Note that the metadata I set has Artist set to Children and Genre set as Vocal, but when export multiple is used then I get John Greene as Artist and Sermon as the Genre. The default is overriding the user set value. This should NOT be as I understand it.
>>>> 
>>>> The only way I found around it is to set the one I wanted as default then when done revert back to the normal default.
>>>> 
>>>> Cliff
>>>>> On Apr 15, 2021, at 16:03, Bill Wharrie <bi...@go... <mailto:bi...@go...>> wrote:
>>>>> 
>>>>> My understanding of the behaviour of Export Multiple is that it treats the a) Track Title and b) Track Number as special cases. Whether or not they contain data, they are filled with a) the label text, and b) the “label number” counting from the beginning of the export. This was done in support (I imagine) of those who were digitizing their vinyl , etc. They could fill in the common info (Artist Name, Album Title, etc) then Audacity would fill in the Track Title and Track Number for them. Is this what you’re seeing?
>>>>> 
>>>>>> On 2021/04/15, at 2:37 PM, Cliff <fly...@gm... <mailto:fly...@gm...>> wrote:
>>>>>> 
>>>>>> I read the manual and it doesn’t address this issue. A normal export works fine where user entered is not overwritten by the default.
>>>>>> 
>>>>>> Apparently Export Multiple does not follow the same protocol regarding the default metadata overwriting user entered data or filling in data in empty fields during export. The default overwrites those the user set fields in which the default has data. 
>>>>> 
>>>>> I don’t understand this. What is “default metadata” versus “user entered data”?
>>>>> 
>>>>> “Default” metadata has a particular meaning in Audacity: the metadata Audacity uses if none is supplied.
>>>>> • Set Default: Makes the current list of tag names and non-empty values the default state whenever opening a new, empty project. To clear the default, press Clear then Set Default.
>>>>> Even if you set a Default, if you import a file containing metadata, that metadata will appear in Metadata Editor. If you always want a fixed set of metadata to show after importing a file, you need to save that set as a template then load the template after importing the file.
>>>>> 
>>>>> — Bill
>>>>> 
>>>>> 
>>>>>> Very bad idea. We dealt with this a while back with normal exporting, but apparently what was done didn’t apply to Export Multiple. As it is now it requires the user to first, know that it will do this to what ever he as set in the metadata and secondly he has to set what he wants to be there as default then do the export multiple then go back and put the default back to where it was. The user would not know this happened if he didn’t look at each metadata for each file as it exports. I can’t imagine editing 52 metadata files during export to fix them or uploading files somewhere then finding out the metadata was messed up.
>>>>>> 
>>>>>> Should I log this as a bug?
>>>>>> 
>>>>>> Cliff
>>>>>> 
>>>>>>> On Apr 15, 2021, at 12:36, Peter Sampson <pet...@gm... <mailto:pet...@gm...>> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On Thu, Apr 15, 2021 at 4:26 PM Cliff <fly...@gm... <mailto:fly...@gm...>> wrote:
>>>>>>> I’ve just run into an issue that maybe is my wrong understanding of something, but to me seems like a bug.
>>>>>>> 
>>>>>>> I’m exporting a file that has 52 labels so I want to get 52 files out of it. Trying to export I find it insists on overwriting the Metadata I have with the default metadata. Even the first file does not have what I set as metadata. Is this a bug or just that I have to reset the default metadata for this export then reinstate it afterwards? I thought we had dealt with this issue a while back, but can’t remember for sure.
>>>>>>> 
>>>>>>> I don't know what's supposed to happen - that's the problem when you don't 
>>>>>>> build from specs.  I'm not sure what the Manual has to say abut it.
>>>>>>> 
>>>>>>> Does this behavior differ from a normal Export?
>>>>>>> 
>>>>>>> One thing I do know is that our handling of metadata is and always has been pretty
>>>>>>> average at best - there are several outstanding metadata bugs and a proposal IIRC.
>>>>>>> 
>>>>>>> 
>>>>>>> Certainly when I was using Export Multiple for my LP transcriptions some years back
>>>>>>> I never bothered with metadata in Audacity - I did all tat in iTunes as at the time I was
>>>>>>> making files for my iPods.  Then later I did it all again with my hi-fi jukebox gadget
>>>>>>> as then I wanted to use lossless WAVs - not that the WAVs carry the metadata, rather
>>>>>>> its the database for the jukebox gadget that handles that (and pretty poorly too I might
>>>>>>> add).
>>>>>>> 
>>>>>>> Peter.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Cliff
>> 
>> _______________________________________________
>> Audacity-quality mailing list
>> Aud...@li... <mailto:Aud...@li...>
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality <https://lists.sourceforge.net/lists/listinfo/audacity-quality>
> 
> _______________________________________________
> Audacity-quality mailing list
> Aud...@li... <mailto:Aud...@li...>
> https://lists.sourceforge.net/lists/listinfo/audacity-quality <https://lists.sourceforge.net/lists/listinfo/audacity-quality>
> _______________________________________________
> Audacity-quality mailing list
> Aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

Re: [Audacity-quality] Export Multiple Bug?

[Peter S. <pet...@gm...>]

On Fri, Apr 16, 2021 at 1:20 AM Bill Wharrie <bi...@go...> wrote:

> Could folks test this when you get a chance?
>
> I’m not suggesting we hold up 3.0.2 for this (since it goes back to 2.4.0
> and Cliff seems the first to notice) so there’s no panic to test it soon.
> I’d just like to confirm with others what I’m seeing and confirm the steps
> before I open a bug. Thanks.
>

I think there's no chance of this holding up 3.0.2 - as the potential fix
for
moonphase 2700 is far more serious.

Please log this Bug Bill.

Peter.




> Steps to reproduce
>
> With any Audacity (2.4.0 or later; I can’t test earlier), with a new empty
> project:
>
> 1) Open the metadata editor
> 2) Enter some easily-identifiable info in the fields, such as “The Track
> Title”, “The Artist”, “The Album Name”, “The Genre”, “The Comment”. Maybe
> “99” for the Track Number and “2030” for the Year.
> 3) Click “Set Default” and close the metadata editor
> 4) Import or create some audio
> 5) Enter a few labels in preparation for Export Multiple
> 6) Open the metadata editor and enter new information in all the fields,
> or just clear some (such as Year or Genre); make sure to enter something
> different from the defaults.
> 7) Do Export Multiple as MP3
> 8) Import one of the exported files *into a new project*
> 9) Open the metadata editor
> Note:
> The Track Name and Track Number have been filled in properly by the Export
> Multiple command
> All other metadata fields have been filled in from the “defaults” (steps 2
> and 3) rather than what was entered in step 6.
>
> The workaround is to clear all the metadata fields then click “Set
> Defaults”.
>




> — Bill
>
> On 2021/04/15, at 7:55 PM, Bill Wharrie <bi...@go...> wrote:
>
>
>
> On 2021/04/15, at 7:47 PM, Bill Wharrie <bi...@go...> wrote:
>
> Cliff:
> OK, I see it now. IMO this is a bug. I’m not sure yet if it is a
> regression.
>
>
> This wrong behaviour goes back to 2.4.0. I can’t test earlier.
> — Bill
>
>
> The workaround is like this:
> - open the metadata editor
> - clear all the fields
> - click “Set Default”
> This sets the default to all fields empty. Now Audacity will fill in the
> metadata for each exported file correctly.
>
> So you’re right: Audacity is using its “default” metadata to over-ride
> what the user enters.
>
> — Bill
>
> PS: this is what I got:
> Defaults:
>
> <Defaults.png>
>
> What I entered before I did Export Multiple:
> <WhatIWant.png>
>
>
> What I got:
> <WhatIGet.png>
>
> On 2021/04/15, at 5:45 PM, Cliff <fly...@gm...> wrote:
>
> Hi Bill,
>
> I expect to have Track Title and Track Number set in the course of the
> Export Multiple. I’m speaking of other fields as you will see below:
>
> This is  what I set in the project:
>
> <PastedGraphic-3.png>
>
> This is the default:
>
> <PastedGraphic-5.png>
>
>
>
>  This is what I get for the first export of 52:
>
> <PastedGraphic-4.png>
>
> Note that the metadata I set has Artist set to Children and Genre set as
> Vocal, but when export multiple is used then I get John Greene as Artist
> and Sermon as the Genre. The default is overriding the user set value. This
> should NOT be as I understand it.
>
> The only way I found around it is to set the one I wanted as default then
> when done revert back to the normal default.
>
> Cliff
>
> On Apr 15, 2021, at 16:03, Bill Wharrie <bi...@go...> wrote:
>
> My understanding of the behaviour of Export Multiple is that it treats the
> a) Track Title and b) Track Number as special cases. Whether or not they
> contain data, they are filled with a) the label text, and b) the “label
> number” counting from the beginning of the export. This was done in support
> (I imagine) of those who were digitizing their vinyl , etc. They could fill
> in the common info (Artist Name, Album Title, etc) then Audacity would fill
> in the Track Title and Track Number for them. Is this what you’re seeing?
>
> On 2021/04/15, at 2:37 PM, Cliff <fly...@gm...> wrote:
>
> I read the manual and it doesn’t address this issue. A normal export works
> fine where user entered is not overwritten by the default.
>
> Apparently Export Multiple does not follow the same protocol regarding the
> default metadata overwriting user entered data or filling in data in empty
> fields during export. The default overwrites those the user set fields in
> which the default has data.
>
>
> I don’t understand this. What is “default metadata” versus “user entered
> data”?
>
> “Default” metadata has a particular meaning in Audacity: the metadata
> Audacity uses if none is supplied.
> • Set Default: Makes the current list of tag names and non-empty values
> the default state whenever opening a new, empty project. To clear the
> default, press Clear then Set Default.
> Even if you set a Default, if you import a file containing metadata, that
> metadata will appear in Metadata Editor. If you always want a fixed set of
> metadata to show after importing a file, you need to save that set as a
> template then load the template after importing the file.
>
> — Bill
>
>
> Very bad idea. We dealt with this a while back with normal exporting, but
> apparently what was done didn’t apply to Export Multiple. As it is now it
> requires the user to first, know that it will do this to what ever he as
> set in the metadata and secondly he has to set what he wants to be there as
> default then do the export multiple then go back and put the default back
> to where it was. The user would not know this happened if he didn’t look at
> each metadata for each file as it exports. I can’t imagine editing 52
> metadata files during export to fix them or uploading files somewhere then
> finding out the metadata was messed up.
>
> Should I log this as a bug?
>
> Cliff
>
> On Apr 15, 2021, at 12:36, Peter Sampson <pet...@gm...>
> wrote:
>
>
>
> On Thu, Apr 15, 2021 at 4:26 PM Cliff <fly...@gm...> wrote:
>
>> I’ve just run into an issue that maybe is my wrong understanding of
>> something, but to me seems like a bug.
>>
>> I’m exporting a file that has 52 labels so I want to get 52 files out of
>> it. Trying to export I find it insists on overwriting the Metadata I have
>> with the default metadata. Even the first file does not have what I set as
>> metadata. Is this a bug or just that I have to reset the default metadata
>> for this export then reinstate it afterwards? I thought we had dealt with
>> this issue a while back, but can’t remember for sure.
>>
>
> I don't know what's supposed to happen - that's the problem when you don't
>
> build from specs.  I'm not sure what the Manual has to say abut it.
>
> Does this behavior differ from a normal Export?
>
> One thing I do know is that our handling of metadata is and always has
> been pretty
> average at best - there are several outstanding metadata bugs and a
> proposal IIRC.
>
>
> Certainly when I was using Export Multiple for my LP transcriptions some
> years back
> I never bothered with metadata in Audacity - I did all tat in iTunes as at
> the time I was
> making files for my iPods.  Then later I did it all again with my hi-fi
> jukebox gadget
> as then I wanted to use lossless WAVs - not that the WAVs carry the
> metadata, rather
> its the database for the jukebox gadget that handles that (and pretty
> poorly too I might
> add).
>
> Peter.
>
>
>
>> Cliff
>>
>
> _______________________________________________
> Audacity-quality mailing list
> Aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
>
> _______________________________________________
> Audacity-quality mailing list
> Aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

Re: [Audacity-quality] Export Multiple Bug?

[Cliff <fly...@gm...>]

Thanks Bill for verifying what I found.

Please note it is not only MP3 export that it affects, but AIFF and probably the others as well. Hopefully the fix will be a general one and not just for one export mode.

Cliff

> On Apr 15, 2021, at 19:19, Bill Wharrie <bi...@go...> wrote:
> 
> Could folks test this when you get a chance?
> 
> I’m not suggesting we hold up 3.0.2 for this (since it goes back to 2.4.0 and Cliff seems the first to notice) so there’s no panic to test it soon. I’d just like to confirm with others what I’m seeing and confirm the steps before I open a bug. Thanks.
> 
> Steps to reproduce
> 
> With any Audacity (2.4.0 or later; I can’t test earlier), with a new empty project:
> 
> 1) Open the metadata editor
> 2) Enter some easily-identifiable info in the fields, such as “The Track Title”, “The Artist”, “The Album Name”, “The Genre”, “The Comment”. Maybe “99” for the Track Number and “2030” for the Year.
> 3) Click “Set Default” and close the metadata editor
> 4) Import or create some audio
> 5) Enter a few labels in preparation for Export Multiple
> 6) Open the metadata editor and enter new information in all the fields, or just clear some (such as Year or Genre); make sure to enter something different from the defaults.
> 7) Do Export Multiple as MP3
> 8) Import one of the exported files into a new project
> 9) Open the metadata editor
> Note:
> The Track Name and Track Number have been filled in properly by the Export Multiple command
> All other metadata fields have been filled in from the “defaults” (steps 2 and 3) rather than what was entered in step 6.
> 
> The workaround is to clear all the metadata fields then click “Set Defaults”.
> 
> — Bill
> 
>> On 2021/04/15, at 7:55 PM, Bill Wharrie <bi...@go... <mailto:bi...@go...>> wrote:
>> 
>> 
>> 
>>> On 2021/04/15, at 7:47 PM, Bill Wharrie <bi...@go... <mailto:bi...@go...>> wrote:
>>> 
>>> Cliff:
>>> OK, I see it now. IMO this is a bug. I’m not sure yet if it is a regression.
>> 
>> This wrong behaviour goes back to 2.4.0. I can’t test earlier.
>> — Bill
>>> 
>>> The workaround is like this:
>>> - open the metadata editor
>>> - clear all the fields
>>> - click “Set Default”
>>> This sets the default to all fields empty. Now Audacity will fill in the metadata for each exported file correctly.
>>> 
>>> So you’re right: Audacity is using its “default” metadata to over-ride what the user enters.
>>> 
>>> — Bill
>>> 
>>> PS: this is what I got:
>>> Defaults:
>>> 
>>> <Defaults.png>
>>> 
>>> What I entered before I did Export Multiple:
>>> <WhatIWant.png>
>>> 
>>> 
>>> What I got:
>>> <WhatIGet.png>
>>> 
>>>> On 2021/04/15, at 5:45 PM, Cliff <fly...@gm... <mailto:fly...@gm...>> wrote:
>>>> 
>>>> Hi Bill,
>>>> 
>>>> I expect to have Track Title and Track Number set in the course of the Export Multiple. I’m speaking of other fields as you will see below:
>>>> 
>>>> This is  what I set in the project:
>>>> 
>>>> <PastedGraphic-3.png>
>>>> 
>>>> This is the default:
>>>> 
>>>> <PastedGraphic-5.png>
>>>> 
>>>> 
>>>> 
>>>>  This is what I get for the first export of 52:
>>>> 
>>>> <PastedGraphic-4.png>
>>>> 
>>>> Note that the metadata I set has Artist set to Children and Genre set as Vocal, but when export multiple is used then I get John Greene as Artist and Sermon as the Genre. The default is overriding the user set value. This should NOT be as I understand it.
>>>> 
>>>> The only way I found around it is to set the one I wanted as default then when done revert back to the normal default.
>>>> 
>>>> Cliff
>>>>> On Apr 15, 2021, at 16:03, Bill Wharrie <bi...@go... <mailto:bi...@go...>> wrote:
>>>>> 
>>>>> My understanding of the behaviour of Export Multiple is that it treats the a) Track Title and b) Track Number as special cases. Whether or not they contain data, they are filled with a) the label text, and b) the “label number” counting from the beginning of the export. This was done in support (I imagine) of those who were digitizing their vinyl , etc. They could fill in the common info (Artist Name, Album Title, etc) then Audacity would fill in the Track Title and Track Number for them. Is this what you’re seeing?
>>>>> 
>>>>>> On 2021/04/15, at 2:37 PM, Cliff <fly...@gm... <mailto:fly...@gm...>> wrote:
>>>>>> 
>>>>>> I read the manual and it doesn’t address this issue. A normal export works fine where user entered is not overwritten by the default.
>>>>>> 
>>>>>> Apparently Export Multiple does not follow the same protocol regarding the default metadata overwriting user entered data or filling in data in empty fields during export. The default overwrites those the user set fields in which the default has data. 
>>>>> 
>>>>> I don’t understand this. What is “default metadata” versus “user entered data”?
>>>>> 
>>>>> “Default” metadata has a particular meaning in Audacity: the metadata Audacity uses if none is supplied.
>>>>> • Set Default: Makes the current list of tag names and non-empty values the default state whenever opening a new, empty project. To clear the default, press Clear then Set Default.
>>>>> Even if you set a Default, if you import a file containing metadata, that metadata will appear in Metadata Editor. If you always want a fixed set of metadata to show after importing a file, you need to save that set as a template then load the template after importing the file.
>>>>> 
>>>>> — Bill
>>>>> 
>>>>> 
>>>>>> Very bad idea. We dealt with this a while back with normal exporting, but apparently what was done didn’t apply to Export Multiple. As it is now it requires the user to first, know that it will do this to what ever he as set in the metadata and secondly he has to set what he wants to be there as default then do the export multiple then go back and put the default back to where it was. The user would not know this happened if he didn’t look at each metadata for each file as it exports. I can’t imagine editing 52 metadata files during export to fix them or uploading files somewhere then finding out the metadata was messed up.
>>>>>> 
>>>>>> Should I log this as a bug?
>>>>>> 
>>>>>> Cliff
>>>>>> 
>>>>>>> On Apr 15, 2021, at 12:36, Peter Sampson <pet...@gm... <mailto:pet...@gm...>> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On Thu, Apr 15, 2021 at 4:26 PM Cliff <fly...@gm... <mailto:fly...@gm...>> wrote:
>>>>>>> I’ve just run into an issue that maybe is my wrong understanding of something, but to me seems like a bug.
>>>>>>> 
>>>>>>> I’m exporting a file that has 52 labels so I want to get 52 files out of it. Trying to export I find it insists on overwriting the Metadata I have with the default metadata. Even the first file does not have what I set as metadata. Is this a bug or just that I have to reset the default metadata for this export then reinstate it afterwards? I thought we had dealt with this issue a while back, but can’t remember for sure.
>>>>>>> 
>>>>>>> I don't know what's supposed to happen - that's the problem when you don't 
>>>>>>> build from specs.  I'm not sure what the Manual has to say abut it.
>>>>>>> 
>>>>>>> Does this behavior differ from a normal Export?
>>>>>>> 
>>>>>>> One thing I do know is that our handling of metadata is and always has been pretty
>>>>>>> average at best - there are several outstanding metadata bugs and a proposal IIRC.
>>>>>>> 
>>>>>>> 
>>>>>>> Certainly when I was using Export Multiple for my LP transcriptions some years back
>>>>>>> I never bothered with metadata in Audacity - I did all tat in iTunes as at the time I was
>>>>>>> making files for my iPods.  Then later I did it all again with my hi-fi jukebox gadget
>>>>>>> as then I wanted to use lossless WAVs - not that the WAVs carry the metadata, rather
>>>>>>> its the database for the jukebox gadget that handles that (and pretty poorly too I might
>>>>>>> add).
>>>>>>> 
>>>>>>> Peter.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Cliff
>> 
>> _______________________________________________
>> Audacity-quality mailing list
>> Aud...@li... <mailto:Aud...@li...>
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
> 
> _______________________________________________
> Audacity-quality mailing list
> Aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

Re: [Audacity-quality] Export Multiple Bug?

[Bill W. <bi...@go...>]

Could folks test this when you get a chance?

I’m not suggesting we hold up 3.0.2 for this (since it goes back to 2.4.0 and Cliff seems the first to notice) so there’s no panic to test it soon. I’d just like to confirm with others what I’m seeing and confirm the steps before I open a bug. Thanks.

Steps to reproduce

With any Audacity (2.4.0 or later; I can’t test earlier), with a new empty project:

1) Open the metadata editor
2) Enter some easily-identifiable info in the fields, such as “The Track Title”, “The Artist”, “The Album Name”, “The Genre”, “The Comment”. Maybe “99” for the Track Number and “2030” for the Year.
3) Click “Set Default” and close the metadata editor
4) Import or create some audio
5) Enter a few labels in preparation for Export Multiple
6) Open the metadata editor and enter new information in all the fields, or just clear some (such as Year or Genre); make sure to enter something different from the defaults.
7) Do Export Multiple as MP3
8) Import one of the exported files into a new project
9) Open the metadata editor
Note:
The Track Name and Track Number have been filled in properly by the Export Multiple command
All other metadata fields have been filled in from the “defaults” (steps 2 and 3) rather than what was entered in step 6.

The workaround is to clear all the metadata fields then click “Set Defaults”.

— Bill

> On 2021/04/15, at 7:55 PM, Bill Wharrie <bi...@go...> wrote:
> 
> 
> 
>> On 2021/04/15, at 7:47 PM, Bill Wharrie <bi...@go... <mailto:bi...@go...>> wrote:
>> 
>> Cliff:
>> OK, I see it now. IMO this is a bug. I’m not sure yet if it is a regression.
> 
> This wrong behaviour goes back to 2.4.0. I can’t test earlier.
> — Bill
>> 
>> The workaround is like this:
>> - open the metadata editor
>> - clear all the fields
>> - click “Set Default”
>> This sets the default to all fields empty. Now Audacity will fill in the metadata for each exported file correctly.
>> 
>> So you’re right: Audacity is using its “default” metadata to over-ride what the user enters.
>> 
>> — Bill
>> 
>> PS: this is what I got:
>> Defaults:
>> 
>> <Defaults.png>
>> 
>> What I entered before I did Export Multiple:
>> <WhatIWant.png>
>> 
>> 
>> What I got:
>> <WhatIGet.png>
>> 
>>> On 2021/04/15, at 5:45 PM, Cliff <fly...@gm... <mailto:fly...@gm...>> wrote:
>>> 
>>> Hi Bill,
>>> 
>>> I expect to have Track Title and Track Number set in the course of the Export Multiple. I’m speaking of other fields as you will see below:
>>> 
>>> This is  what I set in the project:
>>> 
>>> <PastedGraphic-3.png>
>>> 
>>> This is the default:
>>> 
>>> <PastedGraphic-5.png>
>>> 
>>> 
>>> 
>>>  This is what I get for the first export of 52:
>>> 
>>> <PastedGraphic-4.png>
>>> 
>>> Note that the metadata I set has Artist set to Children and Genre set as Vocal, but when export multiple is used then I get John Greene as Artist and Sermon as the Genre. The default is overriding the user set value. This should NOT be as I understand it.
>>> 
>>> The only way I found around it is to set the one I wanted as default then when done revert back to the normal default.
>>> 
>>> Cliff
>>>> On Apr 15, 2021, at 16:03, Bill Wharrie <bi...@go... <mailto:bi...@go...>> wrote:
>>>> 
>>>> My understanding of the behaviour of Export Multiple is that it treats the a) Track Title and b) Track Number as special cases. Whether or not they contain data, they are filled with a) the label text, and b) the “label number” counting from the beginning of the export. This was done in support (I imagine) of those who were digitizing their vinyl , etc. They could fill in the common info (Artist Name, Album Title, etc) then Audacity would fill in the Track Title and Track Number for them. Is this what you’re seeing?
>>>> 
>>>>> On 2021/04/15, at 2:37 PM, Cliff <fly...@gm... <mailto:fly...@gm...>> wrote:
>>>>> 
>>>>> I read the manual and it doesn’t address this issue. A normal export works fine where user entered is not overwritten by the default.
>>>>> 
>>>>> Apparently Export Multiple does not follow the same protocol regarding the default metadata overwriting user entered data or filling in data in empty fields during export. The default overwrites those the user set fields in which the default has data. 
>>>> 
>>>> I don’t understand this. What is “default metadata” versus “user entered data”?
>>>> 
>>>> “Default” metadata has a particular meaning in Audacity: the metadata Audacity uses if none is supplied.
>>>> • Set Default: Makes the current list of tag names and non-empty values the default state whenever opening a new, empty project. To clear the default, press Clear then Set Default.
>>>> Even if you set a Default, if you import a file containing metadata, that metadata will appear in Metadata Editor. If you always want a fixed set of metadata to show after importing a file, you need to save that set as a template then load the template after importing the file.
>>>> 
>>>> — Bill
>>>> 
>>>> 
>>>>> Very bad idea. We dealt with this a while back with normal exporting, but apparently what was done didn’t apply to Export Multiple. As it is now it requires the user to first, know that it will do this to what ever he as set in the metadata and secondly he has to set what he wants to be there as default then do the export multiple then go back and put the default back to where it was. The user would not know this happened if he didn’t look at each metadata for each file as it exports. I can’t imagine editing 52 metadata files during export to fix them or uploading files somewhere then finding out the metadata was messed up.
>>>>> 
>>>>> Should I log this as a bug?
>>>>> 
>>>>> Cliff
>>>>> 
>>>>>> On Apr 15, 2021, at 12:36, Peter Sampson <pet...@gm... <mailto:pet...@gm...>> wrote:
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Thu, Apr 15, 2021 at 4:26 PM Cliff <fly...@gm... <mailto:fly...@gm...>> wrote:
>>>>>> I’ve just run into an issue that maybe is my wrong understanding of something, but to me seems like a bug.
>>>>>> 
>>>>>> I’m exporting a file that has 52 labels so I want to get 52 files out of it. Trying to export I find it insists on overwriting the Metadata I have with the default metadata. Even the first file does not have what I set as metadata. Is this a bug or just that I have to reset the default metadata for this export then reinstate it afterwards? I thought we had dealt with this issue a while back, but can’t remember for sure.
>>>>>> 
>>>>>> I don't know what's supposed to happen - that's the problem when you don't 
>>>>>> build from specs.  I'm not sure what the Manual has to say abut it.
>>>>>> 
>>>>>> Does this behavior differ from a normal Export?
>>>>>> 
>>>>>> One thing I do know is that our handling of metadata is and always has been pretty
>>>>>> average at best - there are several outstanding metadata bugs and a proposal IIRC.
>>>>>> 
>>>>>> 
>>>>>> Certainly when I was using Export Multiple for my LP transcriptions some years back
>>>>>> I never bothered with metadata in Audacity - I did all tat in iTunes as at the time I was
>>>>>> making files for my iPods.  Then later I did it all again with my hi-fi jukebox gadget
>>>>>> as then I wanted to use lossless WAVs - not that the WAVs carry the metadata, rather
>>>>>> its the database for the jukebox gadget that handles that (and pretty poorly too I might
>>>>>> add).
>>>>>> 
>>>>>> Peter.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Cliff
> 
> _______________________________________________
> Audacity-quality mailing list
> Aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

Re: [Audacity-quality] Export Multiple Bug?

[Bill W. <bi...@go...>]

> On 2021/04/15, at 7:47 PM, Bill Wharrie <bi...@go...> wrote:
> 
> Cliff:
> OK, I see it now. IMO this is a bug. I’m not sure yet if it is a regression.

This wrong behaviour goes back to 2.4.0. I can’t test earlier.
— Bill
> 
> The workaround is like this:
> - open the metadata editor
> - clear all the fields
> - click “Set Default”
> This sets the default to all fields empty. Now Audacity will fill in the metadata for each exported file correctly.
> 
> So you’re right: Audacity is using its “default” metadata to over-ride what the user enters.
> 
> — Bill
> 
> PS: this is what I got:
> Defaults:
> 
> <Defaults.png>
> 
> What I entered before I did Export Multiple:
> <WhatIWant.png>
> 
> 
> What I got:
> <WhatIGet.png>
> 
>> On 2021/04/15, at 5:45 PM, Cliff <fly...@gm... <mailto:fly...@gm...>> wrote:
>> 
>> Hi Bill,
>> 
>> I expect to have Track Title and Track Number set in the course of the Export Multiple. I’m speaking of other fields as you will see below:
>> 
>> This is  what I set in the project:
>> 
>> <PastedGraphic-3.png>
>> 
>> This is the default:
>> 
>> <PastedGraphic-5.png>
>> 
>> 
>> 
>>  This is what I get for the first export of 52:
>> 
>> <PastedGraphic-4.png>
>> 
>> Note that the metadata I set has Artist set to Children and Genre set as Vocal, but when export multiple is used then I get John Greene as Artist and Sermon as the Genre. The default is overriding the user set value. This should NOT be as I understand it.
>> 
>> The only way I found around it is to set the one I wanted as default then when done revert back to the normal default.
>> 
>> Cliff
>>> On Apr 15, 2021, at 16:03, Bill Wharrie <bi...@go... <mailto:bi...@go...>> wrote:
>>> 
>>> My understanding of the behaviour of Export Multiple is that it treats the a) Track Title and b) Track Number as special cases. Whether or not they contain data, they are filled with a) the label text, and b) the “label number” counting from the beginning of the export. This was done in support (I imagine) of those who were digitizing their vinyl , etc. They could fill in the common info (Artist Name, Album Title, etc) then Audacity would fill in the Track Title and Track Number for them. Is this what you’re seeing?
>>> 
>>>> On 2021/04/15, at 2:37 PM, Cliff <fly...@gm... <mailto:fly...@gm...>> wrote:
>>>> 
>>>> I read the manual and it doesn’t address this issue. A normal export works fine where user entered is not overwritten by the default.
>>>> 
>>>> Apparently Export Multiple does not follow the same protocol regarding the default metadata overwriting user entered data or filling in data in empty fields during export. The default overwrites those the user set fields in which the default has data. 
>>> 
>>> I don’t understand this. What is “default metadata” versus “user entered data”?
>>> 
>>> “Default” metadata has a particular meaning in Audacity: the metadata Audacity uses if none is supplied.
>>> • Set Default: Makes the current list of tag names and non-empty values the default state whenever opening a new, empty project. To clear the default, press Clear then Set Default.
>>> Even if you set a Default, if you import a file containing metadata, that metadata will appear in Metadata Editor. If you always want a fixed set of metadata to show after importing a file, you need to save that set as a template then load the template after importing the file.
>>> 
>>> — Bill
>>> 
>>> 
>>>> Very bad idea. We dealt with this a while back with normal exporting, but apparently what was done didn’t apply to Export Multiple. As it is now it requires the user to first, know that it will do this to what ever he as set in the metadata and secondly he has to set what he wants to be there as default then do the export multiple then go back and put the default back to where it was. The user would not know this happened if he didn’t look at each metadata for each file as it exports. I can’t imagine editing 52 metadata files during export to fix them or uploading files somewhere then finding out the metadata was messed up.
>>>> 
>>>> Should I log this as a bug?
>>>> 
>>>> Cliff
>>>> 
>>>>> On Apr 15, 2021, at 12:36, Peter Sampson <pet...@gm... <mailto:pet...@gm...>> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> On Thu, Apr 15, 2021 at 4:26 PM Cliff <fly...@gm... <mailto:fly...@gm...>> wrote:
>>>>> I’ve just run into an issue that maybe is my wrong understanding of something, but to me seems like a bug.
>>>>> 
>>>>> I’m exporting a file that has 52 labels so I want to get 52 files out of it. Trying to export I find it insists on overwriting the Metadata I have with the default metadata. Even the first file does not have what I set as metadata. Is this a bug or just that I have to reset the default metadata for this export then reinstate it afterwards? I thought we had dealt with this issue a while back, but can’t remember for sure.
>>>>> 
>>>>> I don't know what's supposed to happen - that's the problem when you don't 
>>>>> build from specs.  I'm not sure what the Manual has to say abut it.
>>>>> 
>>>>> Does this behavior differ from a normal Export?
>>>>> 
>>>>> One thing I do know is that our handling of metadata is and always has been pretty
>>>>> average at best - there are several outstanding metadata bugs and a proposal IIRC.
>>>>> 
>>>>> 
>>>>> Certainly when I was using Export Multiple for my LP transcriptions some years back
>>>>> I never bothered with metadata in Audacity - I did all tat in iTunes as at the time I was
>>>>> making files for my iPods.  Then later I did it all again with my hi-fi jukebox gadget
>>>>> as then I wanted to use lossless WAVs - not that the WAVs carry the metadata, rather
>>>>> its the database for the jukebox gadget that handles that (and pretty poorly too I might
>>>>> add).
>>>>> 
>>>>> Peter.
>>>>> 
>>>>> 
>>>>> 
>>>>> Cliff