MP3 tag manipulation under pCP

[chill]

So does this suggest a missing dependency in lame? Something that happens when getlocale.tcz is loaded is enough to fix it:

Downloading: bash.tcz
bash.tcz: OK
Downloading: glibc_apps.tcz
glibc_apps.tcz: OK
Downloading: glibc_i18n_locale.tcz
glibc_i18n_locale.tcz: OK
Downloading: glibc_gconv.tcz
glibc_gconv.tcz: OK
Downloading: getlocale.tcz
getlocale.tcz: OK

The extension that's needed is glibc_gconv.tcz.

[Paul Webster]

The extension that's needed is glibc_gconv.tcz.

Well done !

[chill]

Well done !

Life's little victories - more important than ever at the moment!

[ralphy]

The extension that's needed is glibc_gconv.tcz.

Sorry this ended up being such a challenge.

The glibc_gconv extension is also required for the tinycore compiler extension which is why lame worked for me.

I've added glibc_gconv to the pcp-lame extension dependency file and pushed the change to our repository.

Life's little victories - more important than ever at the moment!

Thank you for persevering.

[chill]

The glibc_gconv extension is also required for the tinycore compiler extension which is why lame worked for me.

That's a relief - I had visions of you reporting that you didn't have that extension on your system

I've added glibc_gconv to the pcp-lame extension dependency file and pushed the change to our repository.

Thank you.

[chill]

While I've got you Ralphy, what would it take to compile lame as 64 bit? Does it seem feasible to you that some if the 5x speed difference between my old Ubuntu Macbook and my 4GB RPi4 could be down to 64 bit versus 32 bit?

I'm assuming that it would probably be too complicated, e.g. both versions would need to be provided because some pCP installations can't run 64 bit, and I'd guess that dependencies would also have to be available in both versions. But I won't know for sure unless I ask

[paul-]

We have no 64 bit user space. But yes, it would have to start with a 64bit glibc. Multi lib support is not a trivial task.

My guess is that it it floating point capabilities of the pi. All of our binaries are designed to run on every pi. You “might” get some benefit compiling for the capabilities of the pi4, but then we have to start building processor dependent packages.

[chill]

Thanks Paul - I thought it might be a bit of a long shot.

[chill]

However, I have put the rpi4 specific lame extension on my sf website for you to try.

That's really kind of you Ralphy, thank you. I've just tried it out on a couple of RPi4s - one a 1GB unit, and the other a 4GB unit.

On the 1GB unit I see a 2.55x improvement, and on the 4GB unit I see more or less the same 3x improvement that you do. I'm going to guess that your unit has more than 1GB of memory. If not, the difference might be due to me using an MP3 file as the input, rather than a WAV, so there's a bit of decoding time to factor into my results.

The speed of the 64 bit version on my Ubuntu Macbook (Core 2 Duo, circa 2004 I think) is now only 1.5x faster than my 4GB Pi (whereas it used to be 5x faster). That corresponds closely to the difference in processor speed (2.4 GHz versus 1.5 GHz, a 1.6x difference).

I'm going to store this special binary somewhere safe, and hope that the cumulative time I save with it in the future comes to more than the time you've invested on my behalf!

[ralphy]

Deleted my previous post...turns out that the lame build script was not using the recommended compiler options for even the rpi1.

I rebuilt the pcp-lame extension with them and the encoding results are within a second of the rpi4 specific binary.

Just update the pcp-lame extension from the repository for the faster lame.