audacity-devel — Discussion among Audacity developers

[Audacity-devel] Two GitHub PRs

[Ian M. <Ian...@ie...>]

I have recently made two GitHub PRs (
https://github.com/audacity/audacity/pull/816 and
https://github.com/audacity/audacity/pull/818) that I would like for
someone to review + hopefully merge.

The first (#816) cleans up two different warning types that are enabled by
the default build flags in Fedora. The Wreorder warnings are simply just
about initializer lists with an order different from the class layout - so
it is easily fixed by reordering the initializer list. The second is about
calls to std::move that penalize the compiler from doing NRVA, and these
are fixed by removing those calls and letting the compiler optimize away
the move/copy and construct the value in-place.

The second PR (#818) fixes a type difference between the declaration and
definition for a function in mod-script-pipe module - the second argument
was either an int or size_t (which aren't always the same). This PR makes
the second argument a size_t everywhere.

Thanks,
-Ian

Re: [Audacity-devel] Why are modules in /usr/share?

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

That’s a good and valid point.  I’ll look into the build to see what the deal is…

 

From: Ian McInerney <Ian...@ie...> 
Sent: Tuesday, April 20, 2021 7:19 AM
To: aud...@li...
Subject: [Audacity-devel] Why are modules in /usr/share?

 

Looking at the compilation results of the Fedora build for audacity, I noticed that there is a library file being compiled into /usr/share/audacity//modules/mod-script-pipe.so - which is not good. /usr/share is meant to be architecture-independent files, and any architecture-specific code should be put into the /usr/lib* directories instead of the /usr/share directories - so a better place for it would be /usr/lib64/audacity/modules/mod-script-pipe.so (on 64-bit installs).

 

Thanks,

-Ian

[Audacity-devel] Why are modules in /usr/share?

[Ian M. <Ian...@ie...>]

Looking at the compilation results of the Fedora build for audacity, I
noticed that there is a library file being compiled into
/usr/share/audacity//modules/mod-script-pipe.so - which is not good.
/usr/share is meant to be architecture-independent files, and any
architecture-specific code should be put into the /usr/lib* directories
instead of the /usr/share directories - so a better place for it would
be /usr/lib64/audacity/modules/mod-script-pipe.so (on 64-bit installs).

Thanks,
-Ian

Re: [Audacity-devel] Audacity 3.0.2 Released

[Jack L. <xxj...@gm...>]

Ah, I compiled 3.0.2 and didn't see it fixed in there, didn't check
the git version. Thanks!

On Mon, Apr 19, 2021 at 12:36 PM James Crook <jam...@gm...> wrote:
>
> Already done in https://github.com/audacity/audacity/commit/d47264accfb6e76be035c7903dcccf1510906baf ??
>
> --James.
>
> On Mon, 19 Apr 2021 at 20:29, Jack L. <xxj...@gm...> wrote:
>>
>> Awesome! Can we get this patch in 3.0.3 so it doesn't generate a
>> compile error on FreeBSD :)
>>
>> On Mon, Apr 19, 2021 at 6:31 AM James Crook <jam...@gm...> wrote:
>> >
>> > We've just released our Audacity 3.0.2.  Here's the release announcement:
>> >
>> > https://www.audacityteam.org/audacity-3-0-2-released/
>> >
>> > The freeze on code and strings and manual is now lifted.
>> >
>> > 3.0.3?  I am hoping/expecting we will get more of Paul's restructuring in, in 3.0.3, and that we will do something about the effects manager.  I'll be perfectly happy if everything's a bit quieter than it has been for 3.0.0 to 3.0.2!  We do have GSoC moving into the second stage, so a quieter period is probably wishful thinking.
>> >
>> > --James.
>> > _______________________________________________
>> > audacity-devel mailing list
>> > aud...@li...
>> > https://lists.sourceforge.net/lists/listinfo/audacity-devel
>> _______________________________________________
>> audacity-devel mailing list
>> aud...@li...
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
> _______________________________________________
> audacity-devel mailing list
> aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel

Re: [Audacity-devel] Audacity 3.0.2 Released

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

Already done in
https://github.com/audacity/audacity/commit/d47264accfb6e76be035c7903dcccf1510906baf
??

--James.

On Mon, 19 Apr 2021 at 20:29, Jack L. <xxj...@gm...> wrote:

> Awesome! Can we get this patch in 3.0.3 so it doesn't generate a
> compile error on FreeBSD :)
>
> On Mon, Apr 19, 2021 at 6:31 AM James Crook <jam...@gm...>
> wrote:
> >
> > We've just released our Audacity 3.0.2.  Here's the release announcement:
> >
> > https://www.audacityteam.org/audacity-3-0-2-released/
> >
> > The freeze on code and strings and manual is now lifted.
> >
> > 3.0.3?  I am hoping/expecting we will get more of Paul's restructuring
> in, in 3.0.3, and that we will do something about the effects manager.
> I'll be perfectly happy if everything's a bit quieter than it has been for
> 3.0.0 to 3.0.2!  We do have GSoC moving into the second stage, so a quieter
> period is probably wishful thinking.
> >
> > --James.
> > _______________________________________________
> > audacity-devel mailing list
> > aud...@li...
> > https://lists.sourceforge.net/lists/listinfo/audacity-devel
> _______________________________________________
> audacity-devel mailing list
> aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

Re: [Audacity-devel] Audacity 3.0.2 Released

[Jack L. <xxj...@gm...>]

Awesome! Can we get this patch in 3.0.3 so it doesn't generate a
compile error on FreeBSD :)

On Mon, Apr 19, 2021 at 6:31 AM James Crook <jam...@gm...> wrote:
>
> We've just released our Audacity 3.0.2.  Here's the release announcement:
>
> https://www.audacityteam.org/audacity-3-0-2-released/
>
> The freeze on code and strings and manual is now lifted.
>
> 3.0.3?  I am hoping/expecting we will get more of Paul's restructuring in, in 3.0.3, and that we will do something about the effects manager.  I'll be perfectly happy if everything's a bit quieter than it has been for 3.0.0 to 3.0.2!  We do have GSoC moving into the second stage, so a quieter period is probably wishful thinking.
>
> --James.
> _______________________________________________
> audacity-devel mailing list
> aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel

Re: [Audacity-devel] Audacity 3.0.2 Released...

[<p.b...@io...>]

Dear James,
congratulations and thanks for your incredible work!
I am an deep user of your software and a wwide promoter/evangelizer of it.

I've used it for years, in combination with:
- GoldWave, MuseScore3, BIAB, MS-MovieMaker, VSDC, Cakewalk AWS.

A part some problems related to the no-Snap to Clock (really though) and Change Tempo (sinchro with issues at wave's starting) your application is  awsome. Thanks for your time and your enormous effort.

I am an (old) senior Firmware & Software developer (Assembler, Basic, Cobol, Pascal, C/C++, PHP, MySQL, Ajax, jQuery, Mobile, etc.) and Hardware architect.
But I am also a semi-professional musician (pop, country-rock) playing almost keyboards, bass, guitars and sometimes also singing (with my limitations).

Thus, I've spent some good time to re-arrange/remix songs with new tracks, part recordered live and part written with notation (MuseScore) or created with arrangers (like BIAB). The result has been then imported into Audacity and then post-produced with some A/V Editors like MovieMaker or VSDC.
The process is time consuming, but the result is appreciable (for me).

Now I'm working as Consultant at some Business Development projects, both for the Italian market and some for the Europan ones (mostly Portugal).
In the meantime, I maintain my skills related to HW/SW, Web applications and large Database architectures, mostly Open Source based (MySQL, MariaDB).

Just for your info, I have just tested your 3.0.2 on W7 64 bit (it works).
Thanks for your kind updating and for your contribution.
I hope that I could be helpful for your cause in future.
Best Regards.

P.L. Bonatto
Business Development Manager
Quarteira (Loulè) - PT
+351-920-032022
+39-334-7493200

Re: [Audacity-devel] Audacity 3.0.2 Released

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

Well done everyone.

Also announced on the Audacity forum.

Steve

On Mon, 19 Apr 2021 at 16:33, James Crook <jam...@gm...> wrote:

>
>
> On Mon, 19 Apr 2021 at 16:20, John Colket <jc...@gm...> wrote:
>
>> Doesn't James get to celebrate first?
>>
>> Congratulations, James! ☺
>>
>> On Mon, Apr 19, 2021 at 11:11 AM Peter Sampson <
>> pet...@gm...> wrote:
>>
>>>
>>>
>>> On Mon, Apr 19, 2021 at 2:31 PM James Crook <jam...@gm...>
>>> wrote:
>>>
>>>> We've just released our Audacity 3.0.2.  Here's the release
>>>> announcement:
>>>>
>>>> https://www.audacityteam.org/audacity-3-0-2-released/
>>>>
>>>
>>> Well done James !
>>>
>>
> It's well done everyone!  I get to write the release announcement, and
> actually push the release up, but we wouldn't have got here without the
> hard work of multiple people.  Jack's work on 2700 was crucial, the most
> important single thing in 3.0.2.  Without it we'd have only had a release
> with better diagnostics, and not the new code that fixes at the least the
> case Jack was seeing of 2700.
>
> It's a real cliche that this kind of thing is teamwork, but quite honestly
> without multiple translators willing to get translations done quickly,
> testing, retests, changes and bugzilla updates, documentation, help to and
> collecting of feedback from users, and multiple coders working on the code
> we wouldn't have got to here now.
>
> So thanks to everyone.  We should be careful about celebrating.  If we
> celebrate too loudly things have a habit of rebounding.  But we can be
> collectively pleased/proud of having worked effectively together to make
> something good for other people in Audacity 3.0.2.
>
>
>
>>
>>>
>>>
>>>>
>>>> The freeze on code and strings and manual is now lifted.
>>>>
>>>> 3.0.3?  I am hoping/expecting we will get more of Paul's restructuring
>>>> in, in 3.0.3, and that we will do something about the effects manager
>>>> <https://bugzilla.audacityteam.org/show_bug.cgi?id=2452>.  I'll be
>>>> perfectly happy if everything's a bit quieter than it has been for 3.0.0 to
>>>> 3.0.2!  We do have GSoC moving into the second stage, so a quieter period
>>>> is probably wishful thinking.
>>>>
>>>
>>> For 3.0.3 (wearing QA hat) I would really like to see us sort this
>>> proposal
>>>
>>> https://wiki.audacityteam.org/wiki/Proposal:_Rationalizing_where_new_tracks_are_created_to_aid_usability_and_consistency
>>> Which has these two attendant bugs
>>> *Bug 2219* <https://bugzilla.audacityteam.org/show_bug.cgi?id=2219> - ENH:
>>> Add new track places the track at the bottom of the project - should be
>>> under user control
>>> *Bug 2220* <https://bugzilla.audacityteam.org/show_bug.cgi?id=2220> - ENH:
>>> Duplicate command places the duplicate track(s) at the bottom of the
>>> project -not under the selected track(s)
>>>
>>> Documented in
>>>
>>> https://wiki.audacityteam.org/wiki/Next_Release#Requests_to_the_RM_for_3.0.3
>>>
>>> The current behavior(s) annoy a lot of Forum posters over the years.
>>>
>>> Peter.
>>>
>>>
>>>
>>>> --James.
>>>> _______________________________________________
>>>> audacity-devel mailing list
>>>> aud...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>>
>>> _______________________________________________
>>> audacity-devel mailing list
>>> aud...@li...
>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>
>> _______________________________________________
>> audacity-devel mailing list
>> aud...@li...
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
> _______________________________________________
> audacity-devel mailing list
> aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

Re: [Audacity-devel] Audacity 3.0.2 Released

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

On Mon, 19 Apr 2021 at 16:20, John Colket <jc...@gm...> wrote:

> Doesn't James get to celebrate first?
>
> Congratulations, James! ☺
>
> On Mon, Apr 19, 2021 at 11:11 AM Peter Sampson <
> pet...@gm...> wrote:
>
>>
>>
>> On Mon, Apr 19, 2021 at 2:31 PM James Crook <jam...@gm...>
>> wrote:
>>
>>> We've just released our Audacity 3.0.2.  Here's the release announcement:
>>>
>>> https://www.audacityteam.org/audacity-3-0-2-released/
>>>
>>
>> Well done James !
>>
>
It's well done everyone!  I get to write the release announcement, and
actually push the release up, but we wouldn't have got here without the
hard work of multiple people.  Jack's work on 2700 was crucial, the most
important single thing in 3.0.2.  Without it we'd have only had a release
with better diagnostics, and not the new code that fixes at the least the
case Jack was seeing of 2700.

It's a real cliche that this kind of thing is teamwork, but quite honestly
without multiple translators willing to get translations done quickly,
testing, retests, changes and bugzilla updates, documentation, help to and
collecting of feedback from users, and multiple coders working on the code
we wouldn't have got to here now.

So thanks to everyone.  We should be careful about celebrating.  If we
celebrate too loudly things have a habit of rebounding.  But we can be
collectively pleased/proud of having worked effectively together to make
something good for other people in Audacity 3.0.2.



>
>>
>>
>>>
>>> The freeze on code and strings and manual is now lifted.
>>>
>>> 3.0.3?  I am hoping/expecting we will get more of Paul's restructuring
>>> in, in 3.0.3, and that we will do something about the effects manager
>>> <https://bugzilla.audacityteam.org/show_bug.cgi?id=2452>.  I'll be
>>> perfectly happy if everything's a bit quieter than it has been for 3.0.0 to
>>> 3.0.2!  We do have GSoC moving into the second stage, so a quieter period
>>> is probably wishful thinking.
>>>
>>
>> For 3.0.3 (wearing QA hat) I would really like to see us sort this
>> proposal
>>
>> https://wiki.audacityteam.org/wiki/Proposal:_Rationalizing_where_new_tracks_are_created_to_aid_usability_and_consistency
>> Which has these two attendant bugs
>> *Bug 2219* <https://bugzilla.audacityteam.org/show_bug.cgi?id=2219> - ENH:
>> Add new track places the track at the bottom of the project - should be
>> under user control
>> *Bug 2220* <https://bugzilla.audacityteam.org/show_bug.cgi?id=2220> - ENH:
>> Duplicate command places the duplicate track(s) at the bottom of the
>> project -not under the selected track(s)
>>
>> Documented in
>>
>> https://wiki.audacityteam.org/wiki/Next_Release#Requests_to_the_RM_for_3.0.3
>>
>> The current behavior(s) annoy a lot of Forum posters over the years.
>>
>> Peter.
>>
>>
>>
>>> --James.
>>> _______________________________________________
>>> audacity-devel mailing list
>>> aud...@li...
>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>
>> _______________________________________________
>> audacity-devel mailing list
>> aud...@li...
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
> _______________________________________________
> audacity-devel mailing list
> aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

Re: [Audacity-devel] Audacity 3.0.2 Released

[John C. <jc...@gm...>]

Doesn't James get to celebrate first?

Congratulations, James! ☺

On Mon, Apr 19, 2021 at 11:11 AM Peter Sampson <
pet...@gm...> wrote:

>
>
> On Mon, Apr 19, 2021 at 2:31 PM James Crook <jam...@gm...>
> wrote:
>
>> We've just released our Audacity 3.0.2.  Here's the release announcement:
>>
>> https://www.audacityteam.org/audacity-3-0-2-released/
>>
>
> Well done James !
>
>
>
>>
>> The freeze on code and strings and manual is now lifted.
>>
>> 3.0.3?  I am hoping/expecting we will get more of Paul's restructuring
>> in, in 3.0.3, and that we will do something about the effects manager
>> <https://bugzilla.audacityteam.org/show_bug.cgi?id=2452>.  I'll be
>> perfectly happy if everything's a bit quieter than it has been for 3.0.0 to
>> 3.0.2!  We do have GSoC moving into the second stage, so a quieter period
>> is probably wishful thinking.
>>
>
> For 3.0.3 (wearing QA hat) I would really like to see us sort this proposal
>
> https://wiki.audacityteam.org/wiki/Proposal:_Rationalizing_where_new_tracks_are_created_to_aid_usability_and_consistency
> Which has these two attendant bugs
> *Bug 2219* <https://bugzilla.audacityteam.org/show_bug.cgi?id=2219> - ENH:
> Add new track places the track at the bottom of the project - should be
> under user control
> *Bug 2220* <https://bugzilla.audacityteam.org/show_bug.cgi?id=2220> - ENH:
> Duplicate command places the duplicate track(s) at the bottom of the
> project -not under the selected track(s)
>
> Documented in
>
> https://wiki.audacityteam.org/wiki/Next_Release#Requests_to_the_RM_for_3.0.3
>
> The current behavior(s) annoy a lot of Forum posters over the years.
>
> Peter.
>
>
>
>> --James.
>> _______________________________________________
>> audacity-devel mailing list
>> aud...@li...
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
> _______________________________________________
> audacity-devel mailing list
> aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

Re: [Audacity-devel] Audacity 3.0.2 Released

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

On Mon, Apr 19, 2021 at 2:31 PM James Crook <jam...@gm...> wrote:

> We've just released our Audacity 3.0.2.  Here's the release announcement:
>
> https://www.audacityteam.org/audacity-3-0-2-released/
>

Well done James !



>
> The freeze on code and strings and manual is now lifted.
>
> 3.0.3?  I am hoping/expecting we will get more of Paul's restructuring in,
> in 3.0.3, and that we will do something about the effects manager
> <https://bugzilla.audacityteam.org/show_bug.cgi?id=2452>.  I'll be
> perfectly happy if everything's a bit quieter than it has been for 3.0.0 to
> 3.0.2!  We do have GSoC moving into the second stage, so a quieter period
> is probably wishful thinking.
>

For 3.0.3 (wearing QA hat) I would really like to see us sort this proposal
https://wiki.audacityteam.org/wiki/Proposal:_Rationalizing_where_new_tracks_are_created_to_aid_usability_and_consistency
Which has these two attendant bugs
*Bug 2219* <https://bugzilla.audacityteam.org/show_bug.cgi?id=2219> - ENH:
Add new track places the track at the bottom of the project - should be
under user control
*Bug 2220* <https://bugzilla.audacityteam.org/show_bug.cgi?id=2220> - ENH:
Duplicate command places the duplicate track(s) at the bottom of the
project -not under the selected track(s)

Documented in
https://wiki.audacityteam.org/wiki/Next_Release#Requests_to_the_RM_for_3.0.3

The current behavior(s) annoy a lot of Forum posters over the years.

Peter.



> --James.
> _______________________________________________
> audacity-devel mailing list
> aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

[Audacity-devel] Audacity 3.0.2 Released

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

We've just released our Audacity 3.0.2.  Here's the release announcement:

https://www.audacityteam.org/audacity-3-0-2-released/

The freeze on code and strings and manual is now lifted.

3.0.3?  I am hoping/expecting we will get more of Paul's restructuring in,
in 3.0.3, and that we will do something about the effects manager
<https://bugzilla.audacityteam.org/show_bug.cgi?id=2452>.  I'll be
perfectly happy if everything's a bit quieter than it has been for 3.0.0 to
3.0.2!  We do have GSoC moving into the second stage, so a quieter period
is probably wishful thinking.

--James.

Re: [Audacity-devel] location of debug report zip

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

Is there mot a clue here in the path name which contains:
"*Wondershare*" which is a third-part software supplier ?

So maybe it is a bug in someone else's software ?
Or a plug-in that is not playing nicely with Audacity?

Peter.



On Sun, Apr 18, 2021 at 8:31 PM Leland <ll...@ho...> wrote:

> It uses wxFileName::GetTempDir() which checks the TMPDIR, TMP, and TEMP
> environment variables. And then (on Windows) it calls the Windows
> GetTempPath() API, which does this:
>
>    1. The path specified by the TMP environment variable.
>    2. The path specified by the TEMP environment variable.
>    3. The path specified by the USERPROFILE environment variable.
>    4. The Windows directory.
>
> So, maybe there’s a TMPDIR or TMP environment variable that is specifying
> the unusual path.
>
>
>
> *From:* Steve Fiddle <ste...@gm...>
> *Sent:* Sunday, April 18, 2021 12:36 PM
> *To:* Audacity-Devel list <aud...@li...>
> *Subject:* Re: [Audacity-devel] location of debug report zip
>
>
>
>
>
>
>
> On Sun, 18 Apr 2021 at 18:16, Leland <ll...@ho...> wrote:
>
> It should be in what is returned by wxFileName::GetTempDir() since we
> don’t override the directory.  For me that is
> C:\Users\Yam\AppData\Local\Temp and is what the environment variable %TEMP%
> points to.  (ß I’d check the TEMP var first)
>
>
>
> That's what I thought, but:
>
>
>
> 1. I asked them to run:
>
> ECHO %Temp%
>
> and they got:
>
> C:\Users\Brian\AppData\Local\Temp
>
>
>
> 2. Their audacity.cfg contains:
>
> TempDir=C:\\Users\\Brian\\AppData\\Local\\Audacity\\SessionData
>
>
>
> Yet this is a screenshot of the debug report message:
>
>
>
> Any idea what's going on here?
>
>
>
> Steve
>
>
>
>
>
>
>
> *From:* Steve Fiddle <ste...@gm...>
> *Sent:* Sunday, April 18, 2021 10:17 AM
> *To:* Audacity-Devel list <aud...@li...>
> *Subject:* [Audacity-devel] location of debug report zip
>
>
>
> We have a user on the forum that is getting repeated crashes with 3.0.0
> and 2.4.2 when they try to save or export.
>
>
>
> I noticed that the debug report ZIP file was being written to:
>
> C:\Users\Public\Documents\Wondershare\CreatorTemp\
>
>
>
> That's not normal is it?
>
>
>
> Steve
>
> _______________________________________________
> audacity-devel mailing list
> aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
> _______________________________________________
> audacity-devel mailing list
> aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

[Audacity-devel] Disabling MIDI compilation failure

[Jack L. <xxj...@gm...>]

It looks like building audacity without MIDI support is causing a
compilation failure.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255186

Re: [Audacity-devel] location of debug report zip

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

It uses wxFileName::GetTempDir() which checks the TMPDIR, TMP, and TEMP environment variables. And then (on Windows) it calls the Windows GetTempPath() API, which does this:

1.	The path specified by the TMP environment variable.
2.	The path specified by the TEMP environment variable.
3.	The path specified by the USERPROFILE environment variable.
4.	The Windows directory.

So, maybe there’s a TMPDIR or TMP environment variable that is specifying the unusual path.

 

From: Steve Fiddle <ste...@gm...> 
Sent: Sunday, April 18, 2021 12:36 PM
To: Audacity-Devel list <aud...@li...>
Subject: Re: [Audacity-devel] location of debug report zip

 

 

 

On Sun, 18 Apr 2021 at 18:16, Leland <ll...@ho... <mailto:ll...@ho...> > wrote:

It should be in what is returned by wxFileName::GetTempDir() since we don’t override the directory.  For me that is C:\Users\Yam\AppData\Local\Temp and is what the environment variable %TEMP% points to.  (<-- I’d check the TEMP var first)

 

That's what I thought, but:

 

1. I asked them to run:

ECHO %Temp% 

and they got:

C:\Users\Brian\AppData\Local\Temp

 

2. Their audacity.cfg contains:

TempDir=C:\\Users\\Brian\\AppData\\Local\\Audacity\\SessionData

 

Yet this is a screenshot of the debug report message:

 



Any idea what's going on here?

 

Steve

 

 

 

From: Steve Fiddle <ste...@gm... <mailto:ste...@gm...> > 
Sent: Sunday, April 18, 2021 10:17 AM
To: Audacity-Devel list <aud...@li... <mailto:aud...@li...> >
Subject: [Audacity-devel] location of debug report zip

 

We have a user on the forum that is getting repeated crashes with 3.0.0 and 2.4.2 when they try to save or export.

 

I noticed that the debug report ZIP file was being written to:

C:\Users\Public\Documents\Wondershare\CreatorTemp\

 

That's not normal is it?

 

Steve

_______________________________________________
audacity-devel mailing list
aud...@li... <mailto:aud...@li...> 
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Re: [Audacity-devel] location of debug report zip

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

On Sun, 18 Apr 2021 at 18:16, Leland <ll...@ho...> wrote:

> It should be in what is returned by wxFileName::GetTempDir() since we
> don’t override the directory.  For me that is
> C:\Users\Yam\AppData\Local\Temp and is what the environment variable %TEMP%
> points to.  (ß I’d check the TEMP var first)
>

That's what I thought, but:

1. I asked them to run:
ECHO %Temp%
and they got:
C:\Users\Brian\AppData\Local\Temp

2. Their audacity.cfg contains:
TempDir=C:\\Users\\Brian\\AppData\\Local\\Audacity\\SessionData

Yet this is a screenshot of the debug report message:

[image: Error screen.png]
Any idea what's going on here?

Steve



>
> *From:* Steve Fiddle <ste...@gm...>
> *Sent:* Sunday, April 18, 2021 10:17 AM
> *To:* Audacity-Devel list <aud...@li...>
> *Subject:* [Audacity-devel] location of debug report zip
>
>
>
> We have a user on the forum that is getting repeated crashes with 3.0.0
> and 2.4.2 when they try to save or export.
>
>
>
> I noticed that the debug report ZIP file was being written to:
>
> C:\Users\Public\Documents\Wondershare\CreatorTemp\
>
>
>
> That's not normal is it?
>
>
>
> Steve
> _______________________________________________
> audacity-devel mailing list
> aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

Re: [Audacity-devel] location of debug report zip

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

It should be in what is returned by wxFileName::GetTempDir() since we don’t override the directory.  For me that is C:\Users\Yam\AppData\Local\Temp and is what the environment variable %TEMP% points to.  (<-- I’d check the TEMP var first)

 

From: Steve Fiddle <ste...@gm...> 
Sent: Sunday, April 18, 2021 10:17 AM
To: Audacity-Devel list <aud...@li...>
Subject: [Audacity-devel] location of debug report zip

 

We have a user on the forum that is getting repeated crashes with 3.0.0 and 2.4.2 when they try to save or export.

 

I noticed that the debug report ZIP file was being written to:

C:\Users\Public\Documents\Wondershare\CreatorTemp\

 

That's not normal is it?

 

Steve

Re: [Audacity-devel] location of debug report zip

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

On Sun, Apr 18, 2021 at 4:18 PM Steve Fiddle <ste...@gm...>
wrote:

> We have a user on the forum that is getting repeated crashes with 3.0.0
> and 2.4.2 when they try to save or export.
>
> I noticed that the debug report ZIP file was being written to:
> C:\Users\Public\Documents\Wondershare\CreatorTemp\
>
> That's not normal is it?
>

I don't think so - I don't recall ever seeing a debug report sent anywhere
other
than on my PC and in my user-space.

This looks most odd.

Peter.



> Steve
> _______________________________________________
> audacity-devel mailing list
> aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

[Audacity-devel] location of debug report zip

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

We have a user on the forum that is getting repeated crashes with 3.0.0 and
2.4.2 when they try to save or export.

I noticed that the debug report ZIP file was being written to:
C:\Users\Public\Documents\Wondershare\CreatorTemp\

That's not normal is it?

Steve

Re: [Audacity-devel] "Perfect" MP3 fails to import

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

On Thu, 15 Apr 2021 at 18:05, Leland <ll...@ho...> wrote:

> How about using the error callback only while identifying MP3 files and
> then disable it while doing the actual import?  In this case, the file
> imports just fine.  There might be some audio glitch where the error is,
> but I can’t hear it (I didn’t listen to the whole file).
>

We may need to do something to prevent NaNs. We've had problems with NaN
samples in the past, but I've not seen any since we enabled libmad error
checking. NaN sample problems can be hard to identify, but just a single
NaN can cause devastating corruption further down the line.

Steve



>
>
> *From:* Leland <ll...@ho...>
> *Sent:* Thursday, April 15, 2021 11:27 AM
> *To:* aud...@li...
> *Subject:* Re: [Audacity-devel] "Perfect" MP3 fails to import
>
>
>
> Gave it a try butit still throws the Huffman error.
>
>
>
> *From:* James Crook <jam...@gm...>
> *Sent:* Thursday, April 15, 2021 10:52 AM
> *To:* audacity-devel <aud...@li...>
> *Subject:* Re: [Audacity-devel] "Perfect" MP3 fails to import
>
>
>
> With that mp3 file we reach this point in layer3.c, with cachesz == 20 and
> bits_left == -22
>
>   if (cachesz + bits_left < 0)
>     return MAD_ERROR_BADHUFFDATA;  /* big_values overrun */
>
>
> There's a patch here that addresses length issues and changes that code:
>
> https://fossies.org/linux/avidemux/avidemux_plugins/ADM_audioDecoders/ADM_ad_mad/patches/length-check.patch
>
>    635 +     if (cachesz - fakebits < 1)
>
>   636 +       return MAD_ERROR_BADHUFFDATA;
>
>   637       xrptr[1] = MASK1BIT(bitcache, cachesz--) ?
>
>   638         -requantized : requantized;
>
>   639     }
>
>   640 @@ -1155,9 +1221,6 @@ enum mad_error III_huffdecode(struct mad
>
>   641      }
>
>   642    }
>
>   643
>
>   644 *-  if (cachesz + bits_left < 0)*
>
>   645 *-    return MAD_ERROR_BADHUFFDATA;  /* big_values overrun */*
>
>   646 *-*
>
>   647
>
>
>
> The patch looks pretty extensive.
>
>
>
>     From: Kurt Roeckx <ku...@ro...>
>     Date: Sun, 28 Jan 2018 19:26:36 +0100
>     Subject: Check the size before reading with mad_bit_read
>
>
>     There are various cases where it attempts to read past the end of the
> buffer
>     using mad_bit_read(). Most functions didn't even know the size of the
> buffer
>     they were reading from.
>
> We are using libmad 0.15.1b.
> Debian have  0.15.2b-9 with these fixes from 2018 in.
>
> This would need careful review.  Probably worth contacting Kurt Roeckx
> too, to confirm we're understanding things correctly, and say thank you.
>
>
>
> --James.
>
>
>
>
>
> On Thu, 15 Apr 2021 at 15:48, Steve Fiddle <ste...@gm...>
> wrote:
>
>
>
>
>
> On Thu, 15 Apr 2021 at 15:41, James Crook <jam...@gm...> wrote:
>
> Your first message never made it to this list (I just checked the archive).
> What's the link for the mp3?
>
>
>
> You can get it here:
> https://drive.google.com/file/d/1qCPXtsBfFII2NwsSVMZY9k-Lx6sbhlS8/view?usp=sharing
>
>
>
> Steve
>
>
>
>
>
> On Thu, 15 Apr 2021 at 15:35, Steve Fiddle <ste...@gm...>
> wrote:
>
> Good detective work James.
>
>
>
> Any ideas about the MP3 file (first post of this thread)? Given your
> explanation of the OGG problem, I assume that it is a different issue.
>
>
>
> I'm thinking that it is probably an Audacity bug because the file appears
> to be a valid MP3 file. On the other hand, if the MP3 is malformed (in some
> way that I've not been able to detect), then it's rather more open to
> opinion whether or not it is an Audacity bug, or a bug in the application
> that created it.
>
>
>
> Steve
>
>
>
> On Thu, 15 Apr 2021 at 13:43, James Crook <jam...@gm...> wrote:
>
> Logged as: https://bugzilla.audacityteam.org/show_bug.cgi?id=2748
>
>
>
> On Thu, 15 Apr 2021 at 13:27, James Crook <jam...@gm...> wrote:
>
> It's the same infinite loop as JUCE had:
>
>
> https://forum.juce.com/t/ogg-vorbis-file-puts-juce-oggreader-in-infinite-loop/41148
>
> So will be fixed if we upgrade to 1.3.7 or later.
>
>
>
> On Thu, 15 Apr 2021 at 13:00, James Crook <jam...@gm...> wrote:
>
> On both 3.0.2 and 2.4.2 it's stuck in library file, vorbisfile.c
>
> static int _fseek64_wrap(FILE *f,ogg_int64_t off,int whence){
>   if(f==NULL)return(-1);
>   return fseek(f,off,whence);
> }
>
> 'off' and 'whence' are both zero ( SEEK_SET ==0, SEEK_CUR==1,
> SEEK_END==2).  We're compiled 32 bit on windows.  Anyone know if it hangs
> on mac/linux (compiled 64 bit) too?
>
>
>
> --James.
>
>
>
> On Thu, 15 Apr 2021 at 12:31, James Crook <jam...@gm...> wrote:
>
> Confirmed freezes for me on Windows.
>
>
>
> On Thu, 15 Apr 2021 at 12:20, Steve Fiddle <ste...@gm...>
> wrote:
>
> And by "coincidence" (?), a problem reported importing this ogg file:
>
>
> https://upload.wikimedia.org/wikipedia/commons/0/0f/Claude_Debussy_-_Premi%C3%A8re_Arabesque_-_Patrizia_Prati.ogg
>
>
>
> As with the MP3 file, it can be imported if you select the
> "FFmpeg-compatible files" filter, but in this case, using Audacity's native
> OGG importer causes Audacity to freeze on both Windows and Linux (not
> tested on macOS).
>
>
>
> I don't like coincidences as they may be indicating a deeper problem.
>
>
>
> Steve
>
>
>
> On Thu, 15 Apr 2021 at 12:01, Steve Fiddle <ste...@gm...>
> wrote:
>
> I've tested the attached file with multiple tools in Linux and it appears
> to be perfectly formed, yet Audacity still complains that it is malformed
> and refuses to import it.
>
>
>
> Steve
>
> _______________________________________________
> audacity-devel mailing list
> aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
> _______________________________________________
> audacity-devel mailing list
> aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
> _______________________________________________
> audacity-devel mailing list
> aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
> _______________________________________________
> audacity-devel mailing list
> aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
> _______________________________________________
> audacity-devel mailing list
> aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
> _______________________________________________
> audacity-devel mailing list
> aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

Re: [Audacity-devel] "Perfect" MP3 fails to import

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

How about using the error callback only while identifying MP3 files and then disable it while doing the actual import?  In this case, the file imports just fine.  There might be some audio glitch where the error is, but I can’t hear it (I didn’t listen to the whole file).

 

From: Leland <ll...@ho...> 
Sent: Thursday, April 15, 2021 11:27 AM
To: aud...@li...
Subject: Re: [Audacity-devel] "Perfect" MP3 fails to import

 

Gave it a try butit still throws the Huffman error.

 

From: James Crook <jam...@gm... <mailto:jam...@gm...> > 
Sent: Thursday, April 15, 2021 10:52 AM
To: audacity-devel <aud...@li... <mailto:aud...@li...> >
Subject: Re: [Audacity-devel] "Perfect" MP3 fails to import

 

With that mp3 file we reach this point in layer3.c, with cachesz == 20 and bits_left == -22

  if (cachesz + bits_left < 0)
    return MAD_ERROR_BADHUFFDATA;  /* big_values overrun */


There's a patch here that addresses length issues and changes that code:
https://fossies.org/linux/avidemux/avidemux_plugins/ADM_audioDecoders/ADM_ad_mad/patches/length-check.patch

 
  635 +     if (cachesz - fakebits < 1)
  636 +       return MAD_ERROR_BADHUFFDATA;
  637       xrptr[1] = MASK1BIT(bitcache, cachesz--) ?
  638         -requantized : requantized;
  639     }
  640 @@ -1155,9 +1221,6 @@ enum mad_error III_huffdecode(struct mad
  641      }
  642    }
  643  
  644 -  if (cachesz + bits_left < 0)
  645 -    return MAD_ERROR_BADHUFFDATA;  /* big_values overrun */
  646 -
  647

 

The patch looks pretty extensive.

 

    From: Kurt Roeckx <ku...@ro... <mailto:ku...@ro...> >
    Date: Sun, 28 Jan 2018 19:26:36 +0100
    Subject: Check the size before reading with mad_bit_read


    There are various cases where it attempts to read past the end of the buffer
    using mad_bit_read(). Most functions didn't even know the size of the buffer
    they were reading from.

We are using libmad 0.15.1b.
Debian have  0.15.2b-9 with these fixes from 2018 in.

This would need careful review.  Probably worth contacting Kurt Roeckx too, to confirm we're understanding things correctly, and say thank you.

 

--James.

 

 

On Thu, 15 Apr 2021 at 15:48, Steve Fiddle <ste...@gm... <mailto:ste...@gm...> > wrote:

 

 

On Thu, 15 Apr 2021 at 15:41, James Crook <jam...@gm... <mailto:jam...@gm...> > wrote:

Your first message never made it to this list (I just checked the archive).
What's the link for the mp3?

 

You can get it here: https://drive.google.com/file/d/1qCPXtsBfFII2NwsSVMZY9k-Lx6sbhlS8/view?usp=sharing

 

Steve

 

 

On Thu, 15 Apr 2021 at 15:35, Steve Fiddle <ste...@gm... <mailto:ste...@gm...> > wrote:

Good detective work James.

 

Any ideas about the MP3 file (first post of this thread)? Given your explanation of the OGG problem, I assume that it is a different issue.

 

I'm thinking that it is probably an Audacity bug because the file appears to be a valid MP3 file. On the other hand, if the MP3 is malformed (in some way that I've not been able to detect), then it's rather more open to opinion whether or not it is an Audacity bug, or a bug in the application that created it.

 

Steve

 

On Thu, 15 Apr 2021 at 13:43, James Crook <jam...@gm... <mailto:jam...@gm...> > wrote:

Logged as: https://bugzilla.audacityteam.org/show_bug.cgi?id=2748

 

On Thu, 15 Apr 2021 at 13:27, James Crook <jam...@gm... <mailto:jam...@gm...> > wrote:

It's the same infinite loop as JUCE had:

https://forum.juce.com/t/ogg-vorbis-file-puts-juce-oggreader-in-infinite-loop/41148

So will be fixed if we upgrade to 1.3.7 or later.

 

On Thu, 15 Apr 2021 at 13:00, James Crook <jam...@gm... <mailto:jam...@gm...> > wrote:

On both 3.0.2 and 2.4.2 it's stuck in library file, vorbisfile.c

static int _fseek64_wrap(FILE *f,ogg_int64_t off,int whence){
  if(f==NULL)return(-1);
  return fseek(f,off,whence);
}

'off' and 'whence' are both zero ( SEEK_SET ==0, SEEK_CUR==1, SEEK_END==2).  We're compiled 32 bit on windows.  Anyone know if it hangs on mac/linux (compiled 64 bit) too?

 

--James.

 

On Thu, 15 Apr 2021 at 12:31, James Crook <jam...@gm... <mailto:jam...@gm...> > wrote:

Confirmed freezes for me on Windows.

 

On Thu, 15 Apr 2021 at 12:20, Steve Fiddle <ste...@gm... <mailto:ste...@gm...> > wrote:

And by "coincidence" (?), a problem reported importing this ogg file:

https://upload.wikimedia.org/wikipedia/commons/0/0f/Claude_Debussy_-_Premi%C3%A8re_Arabesque_-_Patrizia_Prati.ogg

 

As with the MP3 file, it can be imported if you select the "FFmpeg-compatible files" filter, but in this case, using Audacity's native OGG importer causes Audacity to freeze on both Windows and Linux (not tested on macOS).

 

I don't like coincidences as they may be indicating a deeper problem.

 

Steve

 

On Thu, 15 Apr 2021 at 12:01, Steve Fiddle <ste...@gm... <mailto:ste...@gm...> > wrote:

I've tested the attached file with multiple tools in Linux and it appears to be perfectly formed, yet Audacity still complains that it is malformed and refuses to import it.

 

Steve

_______________________________________________
audacity-devel mailing list
aud...@li... <mailto:aud...@li...> 
https://lists.sourceforge.net/lists/listinfo/audacity-devel

_______________________________________________
audacity-devel mailing list
aud...@li... <mailto:aud...@li...> 
https://lists.sourceforge.net/lists/listinfo/audacity-devel

_______________________________________________
audacity-devel mailing list
aud...@li... <mailto:aud...@li...> 
https://lists.sourceforge.net/lists/listinfo/audacity-devel

_______________________________________________
audacity-devel mailing list
aud...@li...
https://lists.sourceforge.net/lists/listinfo/audacity-devel

_______________________________________________
audacity-devel mailing list
aud...@li... <mailto:aud...@li...> 
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Re: [Audacity-devel] "Perfect" MP3 fails to import

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

I tried building with libmad 0.15.1b-10ubuntu1 and the file still failed to
import.
Unfortunately I don't know how to confirm if I succeeded building with that
version rather than the local version.

Steve


On Thu, 15 Apr 2021 at 17:29, Leland <ll...@ho...> wrote:

> Gave it a try butit still throws the Huffman error.
>
>
>
> *From:* James Crook <jam...@gm...>
> *Sent:* Thursday, April 15, 2021 10:52 AM
> *To:* audacity-devel <aud...@li...>
> *Subject:* Re: [Audacity-devel] "Perfect" MP3 fails to import
>
>
>
> With that mp3 file we reach this point in layer3.c, with cachesz == 20 and
> bits_left == -22
>
>   if (cachesz + bits_left < 0)
>     return MAD_ERROR_BADHUFFDATA;  /* big_values overrun */
>
>
> There's a patch here that addresses length issues and changes that code:
>
> https://fossies.org/linux/avidemux/avidemux_plugins/ADM_audioDecoders/ADM_ad_mad/patches/length-check.patch
>
>    635 +     if (cachesz - fakebits < 1)
>
>   636 +       return MAD_ERROR_BADHUFFDATA;
>
>   637       xrptr[1] = MASK1BIT(bitcache, cachesz--) ?
>
>   638         -requantized : requantized;
>
>   639     }
>
>   640 @@ -1155,9 +1221,6 @@ enum mad_error III_huffdecode(struct mad
>
>   641      }
>
>   642    }
>
>   643
>
>   644 *-  if (cachesz + bits_left < 0)*
>
>   645 *-    return MAD_ERROR_BADHUFFDATA;  /* big_values overrun */*
>
>   646 *-*
>
>   647
>
>
>
> The patch looks pretty extensive.
>
>
>
>     From: Kurt Roeckx <ku...@ro...>
>     Date: Sun, 28 Jan 2018 19:26:36 +0100
>     Subject: Check the size before reading with mad_bit_read
>
>
>     There are various cases where it attempts to read past the end of the
> buffer
>     using mad_bit_read(). Most functions didn't even know the size of the
> buffer
>     they were reading from.
>
> We are using libmad 0.15.1b.
> Debian have  0.15.2b-9 with these fixes from 2018 in.
>
> This would need careful review.  Probably worth contacting Kurt Roeckx
> too, to confirm we're understanding things correctly, and say thank you.
>
>
>
> --James.
>
>
>
>
>
> On Thu, 15 Apr 2021 at 15:48, Steve Fiddle <ste...@gm...>
> wrote:
>
>
>
>
>
> On Thu, 15 Apr 2021 at 15:41, James Crook <jam...@gm...> wrote:
>
> Your first message never made it to this list (I just checked the archive).
> What's the link for the mp3?
>
>
>
> You can get it here:
> https://drive.google.com/file/d/1qCPXtsBfFII2NwsSVMZY9k-Lx6sbhlS8/view?usp=sharing
>
>
>
> Steve
>
>
>
>
>
> On Thu, 15 Apr 2021 at 15:35, Steve Fiddle <ste...@gm...>
> wrote:
>
> Good detective work James.
>
>
>
> Any ideas about the MP3 file (first post of this thread)? Given your
> explanation of the OGG problem, I assume that it is a different issue.
>
>
>
> I'm thinking that it is probably an Audacity bug because the file appears
> to be a valid MP3 file. On the other hand, if the MP3 is malformed (in some
> way that I've not been able to detect), then it's rather more open to
> opinion whether or not it is an Audacity bug, or a bug in the application
> that created it.
>
>
>
> Steve
>
>
>
> On Thu, 15 Apr 2021 at 13:43, James Crook <jam...@gm...> wrote:
>
> Logged as: https://bugzilla.audacityteam.org/show_bug.cgi?id=2748
>
>
>
> On Thu, 15 Apr 2021 at 13:27, James Crook <jam...@gm...> wrote:
>
> It's the same infinite loop as JUCE had:
>
>
> https://forum.juce.com/t/ogg-vorbis-file-puts-juce-oggreader-in-infinite-loop/41148
>
> So will be fixed if we upgrade to 1.3.7 or later.
>
>
>
> On Thu, 15 Apr 2021 at 13:00, James Crook <jam...@gm...> wrote:
>
> On both 3.0.2 and 2.4.2 it's stuck in library file, vorbisfile.c
>
> static int _fseek64_wrap(FILE *f,ogg_int64_t off,int whence){
>   if(f==NULL)return(-1);
>   return fseek(f,off,whence);
> }
>
> 'off' and 'whence' are both zero ( SEEK_SET ==0, SEEK_CUR==1,
> SEEK_END==2).  We're compiled 32 bit on windows.  Anyone know if it hangs
> on mac/linux (compiled 64 bit) too?
>
>
>
> --James.
>
>
>
> On Thu, 15 Apr 2021 at 12:31, James Crook <jam...@gm...> wrote:
>
> Confirmed freezes for me on Windows.
>
>
>
> On Thu, 15 Apr 2021 at 12:20, Steve Fiddle <ste...@gm...>
> wrote:
>
> And by "coincidence" (?), a problem reported importing this ogg file:
>
>
> https://upload.wikimedia.org/wikipedia/commons/0/0f/Claude_Debussy_-_Premi%C3%A8re_Arabesque_-_Patrizia_Prati.ogg
>
>
>
> As with the MP3 file, it can be imported if you select the
> "FFmpeg-compatible files" filter, but in this case, using Audacity's native
> OGG importer causes Audacity to freeze on both Windows and Linux (not
> tested on macOS).
>
>
>
> I don't like coincidences as they may be indicating a deeper problem.
>
>
>
> Steve
>
>
>
> On Thu, 15 Apr 2021 at 12:01, Steve Fiddle <ste...@gm...>
> wrote:
>
> I've tested the attached file with multiple tools in Linux and it appears
> to be perfectly formed, yet Audacity still complains that it is malformed
> and refuses to import it.
>
>
>
> Steve
>
> _______________________________________________
> audacity-devel mailing list
> aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
> _______________________________________________
> audacity-devel mailing list
> aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
> _______________________________________________
> audacity-devel mailing list
> aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
> _______________________________________________
> audacity-devel mailing list
> aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
> _______________________________________________
> audacity-devel mailing list
> aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
> _______________________________________________
> audacity-devel mailing list
> aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

Re: [Audacity-devel] "Perfect" MP3 fails to import

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

Gave it a try butit still throws the Huffman error.

 

From: James Crook <jam...@gm...> 
Sent: Thursday, April 15, 2021 10:52 AM
To: audacity-devel <aud...@li...>
Subject: Re: [Audacity-devel] "Perfect" MP3 fails to import

 

With that mp3 file we reach this point in layer3.c, with cachesz == 20 and bits_left == -22

  if (cachesz + bits_left < 0)
    return MAD_ERROR_BADHUFFDATA;  /* big_values overrun */


There's a patch here that addresses length issues and changes that code:
https://fossies.org/linux/avidemux/avidemux_plugins/ADM_audioDecoders/ADM_ad_mad/patches/length-check.patch

 
  635 +     if (cachesz - fakebits < 1)
  636 +       return MAD_ERROR_BADHUFFDATA;
  637       xrptr[1] = MASK1BIT(bitcache, cachesz--) ?
  638         -requantized : requantized;
  639     }
  640 @@ -1155,9 +1221,6 @@ enum mad_error III_huffdecode(struct mad
  641      }
  642    }
  643  
  644 -  if (cachesz + bits_left < 0)
  645 -    return MAD_ERROR_BADHUFFDATA;  /* big_values overrun */
  646 -
  647

 

The patch looks pretty extensive.

 

    From: Kurt Roeckx <ku...@ro... <mailto:ku...@ro...> >
    Date: Sun, 28 Jan 2018 19:26:36 +0100
    Subject: Check the size before reading with mad_bit_read


    There are various cases where it attempts to read past the end of the buffer
    using mad_bit_read(). Most functions didn't even know the size of the buffer
    they were reading from.

We are using libmad 0.15.1b.
Debian have  0.15.2b-9 with these fixes from 2018 in.

This would need careful review.  Probably worth contacting Kurt Roeckx too, to confirm we're understanding things correctly, and say thank you.

 

--James.



 

 

On Thu, 15 Apr 2021 at 15:48, Steve Fiddle <ste...@gm... <mailto:ste...@gm...> > wrote:

 

 

On Thu, 15 Apr 2021 at 15:41, James Crook <jam...@gm... <mailto:jam...@gm...> > wrote:

Your first message never made it to this list (I just checked the archive).
What's the link for the mp3?

 

You can get it here: https://drive.google.com/file/d/1qCPXtsBfFII2NwsSVMZY9k-Lx6sbhlS8/view?usp=sharing

 

Steve

 

 

On Thu, 15 Apr 2021 at 15:35, Steve Fiddle <ste...@gm... <mailto:ste...@gm...> > wrote:

Good detective work James.

 

Any ideas about the MP3 file (first post of this thread)? Given your explanation of the OGG problem, I assume that it is a different issue.

 

I'm thinking that it is probably an Audacity bug because the file appears to be a valid MP3 file. On the other hand, if the MP3 is malformed (in some way that I've not been able to detect), then it's rather more open to opinion whether or not it is an Audacity bug, or a bug in the application that created it.

 

Steve

 

On Thu, 15 Apr 2021 at 13:43, James Crook <jam...@gm... <mailto:jam...@gm...> > wrote:

Logged as: https://bugzilla.audacityteam.org/show_bug.cgi?id=2748

 

On Thu, 15 Apr 2021 at 13:27, James Crook <jam...@gm... <mailto:jam...@gm...> > wrote:

It's the same infinite loop as JUCE had:

https://forum.juce.com/t/ogg-vorbis-file-puts-juce-oggreader-in-infinite-loop/41148

So will be fixed if we upgrade to 1.3.7 or later.

 

On Thu, 15 Apr 2021 at 13:00, James Crook <jam...@gm... <mailto:jam...@gm...> > wrote:

On both 3.0.2 and 2.4.2 it's stuck in library file, vorbisfile.c

static int _fseek64_wrap(FILE *f,ogg_int64_t off,int whence){
  if(f==NULL)return(-1);
  return fseek(f,off,whence);
}

'off' and 'whence' are both zero ( SEEK_SET ==0, SEEK_CUR==1, SEEK_END==2).  We're compiled 32 bit on windows.  Anyone know if it hangs on mac/linux (compiled 64 bit) too?

 

--James.

 

On Thu, 15 Apr 2021 at 12:31, James Crook <jam...@gm... <mailto:jam...@gm...> > wrote:

Confirmed freezes for me on Windows.

 

On Thu, 15 Apr 2021 at 12:20, Steve Fiddle <ste...@gm... <mailto:ste...@gm...> > wrote:

And by "coincidence" (?), a problem reported importing this ogg file:

https://upload.wikimedia.org/wikipedia/commons/0/0f/Claude_Debussy_-_Premi%C3%A8re_Arabesque_-_Patrizia_Prati.ogg

 

As with the MP3 file, it can be imported if you select the "FFmpeg-compatible files" filter, but in this case, using Audacity's native OGG importer causes Audacity to freeze on both Windows and Linux (not tested on macOS).

 

I don't like coincidences as they may be indicating a deeper problem.

 

Steve

 

On Thu, 15 Apr 2021 at 12:01, Steve Fiddle <ste...@gm... <mailto:ste...@gm...> > wrote:

I've tested the attached file with multiple tools in Linux and it appears to be perfectly formed, yet Audacity still complains that it is malformed and refuses to import it.

 

Steve

_______________________________________________
audacity-devel mailing list
aud...@li... <mailto:aud...@li...> 
https://lists.sourceforge.net/lists/listinfo/audacity-devel

_______________________________________________
audacity-devel mailing list
aud...@li... <mailto:aud...@li...> 
https://lists.sourceforge.net/lists/listinfo/audacity-devel

_______________________________________________
audacity-devel mailing list
aud...@li... <mailto:aud...@li...> 
https://lists.sourceforge.net/lists/listinfo/audacity-devel

_______________________________________________
audacity-devel mailing list
aud...@li... <mailto:aud...@li...> 
https://lists.sourceforge.net/lists/listinfo/audacity-devel

_______________________________________________
audacity-devel mailing list
aud...@li... <mailto:aud...@li...> 
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Re: [Audacity-devel] "Perfect" MP3 fails to import

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

Logged as bug https://bugzilla.audacityteam.org/show_bug.cgi?id=2749

On Thu, 15 Apr 2021 at 16:52, James Crook <jam...@gm...> wrote:

> With that mp3 file we reach this point in layer3.c, with cachesz == 20 and
> bits_left == -22
>
>   if (cachesz + bits_left < 0)
>     return MAD_ERROR_BADHUFFDATA;  /* big_values overrun */
>
>
> There's a patch here that addresses length issues and changes that code:
>
> https://fossies.org/linux/avidemux/avidemux_plugins/ADM_audioDecoders/ADM_ad_mad/patches/length-check.patch
>
>    635 +     if (cachesz - fakebits < 1)  636 +       return MAD_ERROR_BADHUFFDATA;  637       xrptr[1] = MASK1BIT(bitcache, cachesz--) ?  638         -requantized : requantized;  639     }  640 @@ -1155,9 +1221,6 @@ enum mad_error III_huffdecode(struct mad  641      }  642    }  643    644 -  if (cachesz + bits_left < 0)  645 -    return MAD_ERROR_BADHUFFDATA;  /* big_values overrun */  646 -  647
>
>
> The patch looks pretty extensive.
>
>     From: Kurt Roeckx <ku...@ro...>
>     Date: Sun, 28 Jan 2018 19:26:36 +0100
>     Subject: Check the size before reading with mad_bit_read
>
>     There are various cases where it attempts to read past the end of the
> buffer
>     using mad_bit_read(). Most functions didn't even know the size of the
> buffer
>     they were reading from.
>
> We are using libmad 0.15.1b.
> Debian have  0.15.2b-9 with these fixes from 2018 in.
>
> This would need careful review.  Probably worth contacting Kurt Roeckx
> too, to confirm we're understanding things correctly, and say thank you.
>
> --James.
>
>
>
>
> On Thu, 15 Apr 2021 at 15:48, Steve Fiddle <ste...@gm...>
> wrote:
>
>>
>>
>> On Thu, 15 Apr 2021 at 15:41, James Crook <jam...@gm...>
>> wrote:
>>
>>> Your first message never made it to this list (I just checked the
>>> archive).
>>> What's the link for the mp3?
>>>
>>
>> You can get it here:
>> https://drive.google.com/file/d/1qCPXtsBfFII2NwsSVMZY9k-Lx6sbhlS8/view?usp=sharing
>>
>> Steve
>>
>>
>>>
>>> On Thu, 15 Apr 2021 at 15:35, Steve Fiddle <ste...@gm...>
>>> wrote:
>>>
>>>> Good detective work James.
>>>>
>>>> Any ideas about the MP3 file (first post of this thread)? Given your
>>>> explanation of the OGG problem, I assume that it is a different issue.
>>>>
>>>> I'm thinking that it is probably an Audacity bug because the file
>>>> appears to be a valid MP3 file. On the other hand, if the MP3 is malformed
>>>> (in some way that I've not been able to detect), then it's rather more open
>>>> to opinion whether or not it is an Audacity bug, or a bug in the
>>>> application that created it.
>>>>
>>>> Steve
>>>>
>>>> On Thu, 15 Apr 2021 at 13:43, James Crook <jam...@gm...>
>>>> wrote:
>>>>
>>>>> Logged as: https://bugzilla.audacityteam.org/show_bug.cgi?id=2748
>>>>>
>>>>>
>>>>> On Thu, 15 Apr 2021 at 13:27, James Crook <jam...@gm...>
>>>>> wrote:
>>>>>
>>>>>> It's the same infinite loop as JUCE had:
>>>>>>
>>>>>>
>>>>>> https://forum.juce.com/t/ogg-vorbis-file-puts-juce-oggreader-in-infinite-loop/41148
>>>>>>
>>>>>> So will be fixed if we upgrade to 1.3.7 or later.
>>>>>>
>>>>>> On Thu, 15 Apr 2021 at 13:00, James Crook <jam...@gm...>
>>>>>> wrote:
>>>>>>
>>>>>>> On both 3.0.2 and 2.4.2 it's stuck in library file, vorbisfile.c
>>>>>>>
>>>>>>> static int _fseek64_wrap(FILE *f,ogg_int64_t off,int whence){
>>>>>>>   if(f==NULL)return(-1);
>>>>>>>   return fseek(f,off,whence);
>>>>>>> }
>>>>>>>
>>>>>>> 'off' and 'whence' are both zero ( SEEK_SET ==0, SEEK_CUR==1,
>>>>>>> SEEK_END==2).  We're compiled 32 bit on windows.  Anyone know if it hangs
>>>>>>> on mac/linux (compiled 64 bit) too?
>>>>>>>
>>>>>>> --James.
>>>>>>>
>>>>>>>
>>>>>>> On Thu, 15 Apr 2021 at 12:31, James Crook <jam...@gm...>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Confirmed freezes for me on Windows.
>>>>>>>>
>>>>>>>> On Thu, 15 Apr 2021 at 12:20, Steve Fiddle <
>>>>>>>> ste...@gm...> wrote:
>>>>>>>>
>>>>>>>>> And by "coincidence" (?), a problem reported importing this ogg
>>>>>>>>> file:
>>>>>>>>>
>>>>>>>>> https://upload.wikimedia.org/wikipedia/commons/0/0f/Claude_Debussy_-_Premi%C3%A8re_Arabesque_-_Patrizia_Prati.ogg
>>>>>>>>>
>>>>>>>>> As with the MP3 file, it can be imported if you select the
>>>>>>>>> "FFmpeg-compatible files" filter, but in this case, using Audacity's native
>>>>>>>>> OGG importer causes Audacity to freeze on both Windows and Linux (not
>>>>>>>>> tested on macOS).
>>>>>>>>>
>>>>>>>>> I don't like coincidences as they may be indicating a deeper
>>>>>>>>> problem.
>>>>>>>>>
>>>>>>>>> Steve
>>>>>>>>>
>>>>>>>>> On Thu, 15 Apr 2021 at 12:01, Steve Fiddle <
>>>>>>>>> ste...@gm...> wrote:
>>>>>>>>>
>>>>>>>>>> I've tested the attached file with multiple tools in Linux and it
>>>>>>>>>> appears to be perfectly formed, yet Audacity still complains that it is
>>>>>>>>>> malformed and refuses to import it.
>>>>>>>>>>
>>>>>>>>>> Steve
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> audacity-devel mailing list
>>>>>>>>> aud...@li...
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>> audacity-devel mailing list
>>>>> aud...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>>>
>>>> _______________________________________________
>>>> audacity-devel mailing list
>>>> aud...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>>
>>> _______________________________________________
>>> audacity-devel mailing list
>>> aud...@li...
>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>
>> _______________________________________________
>> audacity-devel mailing list
>> aud...@li...
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
>

Re: [Audacity-devel] "Perfect" MP3 fails to import

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

Libmad is reporting this:

 

MAD_ERROR_BADHUFFDATA          = 0x0238,  /* Huffman data overrun */

 

From: Steve Fiddle <ste...@gm...> 
Sent: Thursday, April 15, 2021 9:47 AM
To: Audacity-Devel list <aud...@li...>
Subject: Re: [Audacity-devel] "Perfect" MP3 fails to import

 

 

 

On Thu, 15 Apr 2021 at 15:41, James Crook <jam...@gm... <mailto:jam...@gm...> > wrote:

Your first message never made it to this list (I just checked the archive).
What's the link for the mp3?

 

You can get it here: https://drive.google.com/file/d/1qCPXtsBfFII2NwsSVMZY9k-Lx6sbhlS8/view?usp=sharing

 

Steve

 

 

On Thu, 15 Apr 2021 at 15:35, Steve Fiddle <ste...@gm... <mailto:ste...@gm...> > wrote:

Good detective work James.

 

Any ideas about the MP3 file (first post of this thread)? Given your explanation of the OGG problem, I assume that it is a different issue.

 

I'm thinking that it is probably an Audacity bug because the file appears to be a valid MP3 file. On the other hand, if the MP3 is malformed (in some way that I've not been able to detect), then it's rather more open to opinion whether or not it is an Audacity bug, or a bug in the application that created it.

 

Steve

 

On Thu, 15 Apr 2021 at 13:43, James Crook <jam...@gm... <mailto:jam...@gm...> > wrote:

Logged as: https://bugzilla.audacityteam.org/show_bug.cgi?id=2748

 

On Thu, 15 Apr 2021 at 13:27, James Crook <jam...@gm... <mailto:jam...@gm...> > wrote:

It's the same infinite loop as JUCE had:

https://forum.juce.com/t/ogg-vorbis-file-puts-juce-oggreader-in-infinite-loop/41148

So will be fixed if we upgrade to 1.3.7 or later.

 

On Thu, 15 Apr 2021 at 13:00, James Crook <jam...@gm... <mailto:jam...@gm...> > wrote:

On both 3.0.2 and 2.4.2 it's stuck in library file, vorbisfile.c

static int _fseek64_wrap(FILE *f,ogg_int64_t off,int whence){
  if(f==NULL)return(-1);
  return fseek(f,off,whence);
}

'off' and 'whence' are both zero ( SEEK_SET ==0, SEEK_CUR==1, SEEK_END==2).  We're compiled 32 bit on windows.  Anyone know if it hangs on mac/linux (compiled 64 bit) too?

 

--James.

 

On Thu, 15 Apr 2021 at 12:31, James Crook <jam...@gm... <mailto:jam...@gm...> > wrote:

Confirmed freezes for me on Windows.

 

On Thu, 15 Apr 2021 at 12:20, Steve Fiddle <ste...@gm... <mailto:ste...@gm...> > wrote:

And by "coincidence" (?), a problem reported importing this ogg file:

https://upload.wikimedia.org/wikipedia/commons/0/0f/Claude_Debussy_-_Premi%C3%A8re_Arabesque_-_Patrizia_Prati.ogg

 

As with the MP3 file, it can be imported if you select the "FFmpeg-compatible files" filter, but in this case, using Audacity's native OGG importer causes Audacity to freeze on both Windows and Linux (not tested on macOS).

 

I don't like coincidences as they may be indicating a deeper problem.

 

Steve

 

On Thu, 15 Apr 2021 at 12:01, Steve Fiddle <ste...@gm... <mailto:ste...@gm...> > wrote:

I've tested the attached file with multiple tools in Linux and it appears to be perfectly formed, yet Audacity still complains that it is malformed and refuses to import it.

 

Steve

_______________________________________________
audacity-devel mailing list
aud...@li... <mailto:aud...@li...> 
https://lists.sourceforge.net/lists/listinfo/audacity-devel

_______________________________________________
audacity-devel mailing list
aud...@li... <mailto:aud...@li...> 
https://lists.sourceforge.net/lists/listinfo/audacity-devel

_______________________________________________
audacity-devel mailing list
aud...@li... <mailto:aud...@li...> 
https://lists.sourceforge.net/lists/listinfo/audacity-devel

_______________________________________________
audacity-devel mailing list
aud...@li... <mailto:aud...@li...> 
https://lists.sourceforge.net/lists/listinfo/audacity-devel