#dnf install mpg123 "No package mpg123 available"
Why is this? I thought mp3 DECODING was safe to distribute, as does Debian https://packages.debian.org/jessie/xmms2-plugin-mad
and that only MP3 *encoding* was actively pursued by the Fraunhoffer Insitute and assorted MP3 cartels. according to this, Debian has been distributing mp3 decoding libs for over 10 years... https://lists.debian.org/debian-legal/2005/07/msg00082.html
FC
On 01/09/16 19:50, Fernando Cassia wrote:
#dnf install mpg123 "No package mpg123 available"
Why is this? I thought mp3 DECODING was safe to distribute, as does Debian https://packages.debian.org/jessie/xmms2-plugin-mad
and that only MP3 *encoding* was actively pursued by the Fraunhoffer Insitute and assorted MP3 cartels. according to this, Debian has been distributing mp3 decoding libs for over 10 years... https://lists.debian.org/debian-legal/2005/07/msg00082.html
mpg123 is available from the rpmfusion repos.
On Sat, Jan 9, 2016 at 7:12 AM, Ed Greshko ed.greshko@greshko.com wrote:
mpg123 is available from the rpmfusion repos.
Thanks Ed!
Is there any side-effect from enabling the rpmfusion repos? Conflict with system libs?
FC
None. I have them enabled myself not a problem. But maybe you'd like to take a look at this article: https://crossingtheair.wordpress.com/2015/12/23/installing-codecs-and-more/ Hope this is useful!
Cheers, Sylvia
On 09/01/2016, Fernando Cassia fcassia@gmail.com wrote:
On Sat, Jan 9, 2016 at 7:12 AM, Ed Greshko ed.greshko@greshko.com wrote:
mpg123 is available from the rpmfusion repos.
Thanks Ed!
Is there any side-effect from enabling the rpmfusion repos? Conflict with system libs?
FC
-- During times of Universal Deceit, telling the truth becomes a revolutionary act Durante épocas de Engaño Universal, decir la verdad se convierte en un Acto Revolucionario
- George Orwell
On Sat, Jan 9, 2016 at 12:06 PM, Sylvia Sánchez lailahfsf@gmail.com wrote:
None. I have them enabled myself not a problem. But maybe you'd like to take a look at this article: https://crossingtheair.wordpress.com/2015/12/23/installing-codecs-and-more/ Hope this is useful!
Thanks Stlv,
And everyone else who replied, for that matter. I have used "Fedy-installer" in the past https://github.com/folkswithhats/fedy which serves the purpose as well.
I was just interested to know why mp3 decoders (not encoders which I know are more troublesome and almost no distro includes), were not included in the main Fedora repos. Some other list members answered with the "legal angle" of that decision. That's what I was after.
It's good to know that after 2017 there'll be likely no barriers to include mp3 decoders in FOSS apps..
Cheers, FC
Manjaro includes decoders. But it's Europe based.
Cheers, Sylvia
On 10/01/2016, Fernando Cassia fcassia@gmail.com wrote:
On Sat, Jan 9, 2016 at 12:06 PM, Sylvia Sánchez lailahfsf@gmail.com wrote:
None. I have them enabled myself not a problem. But maybe you'd like to take a look at this article: https://crossingtheair.wordpress.com/2015/12/23/installing-codecs-and-more/ Hope this is useful!
Thanks Stlv,
And everyone else who replied, for that matter. I have used "Fedy-installer" in the past https://github.com/folkswithhats/fedy which serves the purpose as well.
I was just interested to know why mp3 decoders (not encoders which I know are more troublesome and almost no distro includes), were not included in the main Fedora repos. Some other list members answered with the "legal angle" of that decision. That's what I was after.
It's good to know that after 2017 there'll be likely no barriers to include mp3 decoders in FOSS apps..
Cheers, FC
-- TDuring times of Universal Deceit, telling the truth becomes a revolutionary act Durante épocas de Engaño Universal, decir la verdad se convierte en un Acto Revolucionario
- George Orwell
On Sun, Jan 10, 2016 at 7:47 AM, Sylvia Sánchez lailahfsf@gmail.com wrote:
Manjaro includes decoders. But it's Europe based.
Thanks again Sylv. As does Debian, which I mentioned in my initial message. :)
FC
On Sun, Jan 10, 2016 at 7:47 AM, Sylvia Sánchez lailahfsf@gmail.com wrote:
Manjaro includes decoders. But it's Europe based.
sorry, forgot the link on my previous email. https://packages.debian.org/jessie/libmad0
(just for reference, I'm not trying to make any point here, so no reply is needed).
FC
On Sat, 2016-01-09 at 10:41 -0500, Fernando Cassia wrote:
On Sat, Jan 9, 2016 at 7:12 AM, Ed Greshko ed.greshko@greshko.com wrote:
mpg123 is available from the rpmfusion repos.
Thanks Ed!
Is there any side-effect from enabling the rpmfusion repos? Conflict with system libs?
No, stuff in RPMfusion is there because of license issues, but I've never had a problem with it. I suspect most people on the list have it enabled.
poc
On 01/09/2016 06:21 PM, Patrick O'Callaghan wrote:
On Sat, 2016-01-09 at 10:41 -0500, Fernando Cassia wrote:
On Sat, Jan 9, 2016 at 7:12 AM, Ed Greshko ed.greshko@greshko.com wrote:
mpg123 is available from the rpmfusion repos.
Thanks Ed!
Is there any side-effect from enabling the rpmfusion repos? Conflict with system libs?
No, stuff in RPMfusion is there because of license issues, but I've never had a problem with it. I suspect most people on the list have it enabled.
poc
if you don't want to install all the extra software repos etc... you can just grab the rpms from rpmfusion, unzip and get all the .so files out of them and place them in your .local/share/gstreamer-1.0/plugins folder. a la:
ls .local/share/gstreamer-1.0/plugins/ libgsta52dec.so libgstcdio.so libgstlame.so libgstrmdemux.so libgstamrnb.so libgstdvdlpcmdec.so libgstlibav.so libgsttwolame.so libgstamrwbdec.so libgstdvdread.so libgstmad.so libgstx264.so libgstasf.so libgstdvdsub.so libgstmpeg2dec.so libgstxingmux.so
and most all codecs will now run in your gnome applications without any worries.
On Sat, 2016-01-09 at 19:18 +0100, Philip Brown wrote:
On 01/09/2016 06:21 PM, Patrick O'Callaghan wrote:
On Sat, 2016-01-09 at 10:41 -0500, Fernando Cassia wrote:
On Sat, Jan 9, 2016 at 7:12 AM, Ed Greshko <ed.greshko@greshko.co m> wrote:
mpg123 is available from the rpmfusion repos.
Thanks Ed!
Is there any side-effect from enabling the rpmfusion repos? Conflict with system libs?
No, stuff in RPMfusion is there because of license issues, but I've never had a problem with it. I suspect most people on the list have it enabled.
poc
if you don't want to install all the extra software repos etc... you can just grab the rpms from rpmfusion, unzip and get all the .so files out of them and place them in your .local/share/gstreamer-1.0/plugins folder. a la:
ls .local/share/gstreamer-1.0/plugins/ libgsta52dec.so libgstcdio.so libgstlame.so libgstrmdemux.so libgstamrnb.so libgstdvdlpcmdec.so libgstlibav.so libgsttwolame.so libgstamrwbdec.so libgstdvdread.so libgstmad.so libgstx264.so libgstasf.so libgstdvdsub.so libgstmpeg2dec.so libgstxingmux.so
and most all codecs will now run in your gnome applications without any worries.
That means you get to check back periodically and repeat the process by hand if they've been updated. I don't see why most people would do that. There really isn't a problem enabling RPMfusion repos. They are designed to be used with the standard Fedora repos so you aren't going to magically install stuff that conflicts.
poc
On 01/09/2016 08:16 PM, Patrick O'Callaghan wrote:
On Sat, 2016-01-09 at 19:18 +0100, Philip Brown wrote:
On 01/09/2016 06:21 PM, Patrick O'Callaghan wrote:
On Sat, 2016-01-09 at 10:41 -0500, Fernando Cassia wrote:
On Sat, Jan 9, 2016 at 7:12 AM, Ed Greshko <ed.greshko@greshko.co m> wrote:
mpg123 is available from the rpmfusion repos.
Thanks Ed!
Is there any side-effect from enabling the rpmfusion repos? Conflict with system libs?
No, stuff in RPMfusion is there because of license issues, but I've never had a problem with it. I suspect most people on the list have it enabled.
poc
if you don't want to install all the extra software repos etc... you can just grab the rpms from rpmfusion, unzip and get all the .so files out of them and place them in your .local/share/gstreamer-1.0/plugins folder. a la:
ls .local/share/gstreamer-1.0/plugins/ libgsta52dec.so libgstcdio.so libgstlame.so libgstrmdemux.so libgstamrnb.so libgstdvdlpcmdec.so libgstlibav.so libgsttwolame.so libgstamrwbdec.so libgstdvdread.so libgstmad.so libgstx264.so libgstasf.so libgstdvdsub.so libgstmpeg2dec.so libgstxingmux.so
and most all codecs will now run in your gnome applications without any worries.
That means you get to check back periodically and repeat the process by hand if they've been updated. I don't see why most people would do that. There really isn't a problem enabling RPMfusion repos. They are designed to be used with the standard Fedora repos so you aren't going to magically install stuff that conflicts.
poc
yeah, well, that's just, like, your opinion, man.
On 01/10/16 03:16, Patrick O'Callaghan wrote:
That means you get to check back periodically and repeat the process by hand if they've been updated. I don't see why most people would do that. There really isn't a problem enabling RPMfusion repos. They are designed to be used with the standard Fedora repos so you aren't going to magically install stuff that conflicts.
+1
Yeah, I don't know why anyone would make more work for themselves. :-)
On Sat, 9 Jan 2016 19:18:05 +0100, Philip Brown wrote:
if you don't want to install all the extra software repos etc... you can just grab the rpms from rpmfusion, unzip and get all the .so files out of them and place them in your .local/share/gstreamer-1.0/plugins folder. a la:
ls .local/share/gstreamer-1.0/plugins/ libgsta52dec.so libgstcdio.so libgstlame.so libgstrmdemux.so libgstamrnb.so libgstdvdlpcmdec.so libgstlibav.so libgsttwolame.so libgstamrwbdec.so libgstdvdread.so libgstmad.so libgstx264.so libgstasf.so libgstdvdsub.so libgstmpeg2dec.so libgstxingmux.so
and most all codecs will now run in your gnome applications without any worries.
That seems planless. Not everything people use is based on GStreamer, so adding GStreamer plugins like that doesn't achieve much. And what about the dependencies of those GStreamer plugins? Do you really fetch all those extra rpms and extract them to a local path to be added to runtime linker's search path?
On 01/10/2016 04:36 PM, Michael Schwendt wrote:
On Sat, 9 Jan 2016 19:18:05 +0100, Philip Brown wrote:
if you don't want to install all the extra software repos etc... you can just grab the rpms from rpmfusion, unzip and get all the .so files out of them and place them in your .local/share/gstreamer-1.0/plugins folder. a la:
ls .local/share/gstreamer-1.0/plugins/ libgsta52dec.so libgstcdio.so libgstlame.so libgstrmdemux.so libgstamrnb.so libgstdvdlpcmdec.so libgstlibav.so libgsttwolame.so libgstamrwbdec.so libgstdvdread.so libgstmad.so libgstx264.so libgstasf.so libgstdvdsub.so libgstmpeg2dec.so libgstxingmux.so
and most all codecs will now run in your gnome applications without any worries.
That seems planless.
on the contrary, the information was given to resolve concerns about acquiring codecs without having to install rpmfusion. i think it achieves that.
Not everything people use is based on GStreamer, so adding GStreamer plugins like that doesn't achieve much.
like i said, it is suitable for gnome apps, so that also achieves that.
And what about the dependencies of those GStreamer plugins? Do you really fetch all those extra rpms and extract them to a local path to be added to runtime linker's search path?
no. i extracted like 2 or 3 rpms and put the .so files in my plugins folder.
On 01/10/2016 04:25 PM, Philip Brown wrote:
On 01/10/2016 04:36 PM, Michael Schwendt wrote:
On Sat, 9 Jan 2016 19:18:05 +0100, Philip Brown wrote:
if you don't want to install all the extra software repos etc... you can just grab the rpms from rpmfusion, unzip and get all the .so files out of them and place them in your .local/share/gstreamer-1.0/plugins folder. a la:
ls .local/share/gstreamer-1.0/plugins/ libgsta52dec.so libgstcdio.so libgstlame.so libgstrmdemux.so libgstamrnb.so libgstdvdlpcmdec.so libgstlibav.so libgsttwolame.so libgstamrwbdec.so libgstdvdread.so libgstmad.so libgstx264.so libgstasf.so libgstdvdsub.so libgstmpeg2dec.so libgstxingmux.so
and most all codecs will now run in your gnome applications without any worries.
That seems planless.
on the contrary, the information was given to resolve concerns about acquiring codecs without having to install rpmfusion. i think it achieves that.
/snip/
One way to have all the codecs is to use Mint! They're standard issue. (That's not my OS, but it does solve some problems that other OSs don't.
--doug
On Sun, 10 Jan 2016 22:25:20 +0100, Philip Brown wrote:
on the contrary, the information was given to resolve concerns about acquiring codecs without having to install rpmfusion. i think it achieves that.
The subject is about mpg123, which is not related to GStreamer at all. The message you replied to is about RPMfusion in general.
like i said, it is suitable for gnome apps, so that also achieves that.
And you still would need to resolve dependencies *yourself*, which defeats the purpose of tools like Yum or DNF. They would pull in what's needed. It may even be a specific version of a library package that's needed.
And what about the dependencies of those GStreamer plugins? Do you really fetch all those extra rpms and extract them to a local path to be added to runtime linker's search path?
no. i extracted like 2 or 3 rpms and put the .so files in my plugins folder.
You need at least the following packages as dependencies,
libmad libmimic libmms opencore-amr vo-amrwbenc
for the plugins in "gstreamer1-plugins-bad-freeworld" and "gstreamer1-plugins-ugly".
And a "dnf install gstreamer1-plugins*" here wants to install "35 Packages", while some dependencies probably are installed already.
On 01/10/2016 10:41 PM, Michael Schwendt wrote:
On Sun, 10 Jan 2016 22:25:20 +0100, Philip Brown wrote:
on the contrary, the information was given to resolve concerns about acquiring codecs without having to install rpmfusion. i think it achieves that.
The subject is about mpg123, which is not related to GStreamer at all. The message you replied to is about RPMfusion in general.
like i said, it is suitable for gnome apps, so that also achieves that.
And you still would need to resolve dependencies *yourself*, which defeats the purpose of tools like Yum or DNF. They would pull in what's needed. It may even be a specific version of a library package that's needed.
And what about the dependencies of those GStreamer plugins? Do you really fetch all those extra rpms and extract them to a local path to be added to runtime linker's search path?
no. i extracted like 2 or 3 rpms and put the .so files in my plugins folder.
You need at least the following packages as dependencies,
libmad libmimic libmms opencore-amr vo-amrwbenc
for the plugins in "gstreamer1-plugins-bad-freeworld" and "gstreamer1-plugins-ugly".
And a "dnf install gstreamer1-plugins*" here wants to install "35 Packages", while some dependencies probably are installed already.
Ok Michael, I can see you don't like this.
however, in a couple of very simple steps, this gives me a very usable multimedia system on my default fedora workstation without having to install any additional repos. which for me is awesome.
and I can confirm all I had to do was download and extract .so files from the following 2 rpms: http://download1.rpmfusion.org/free/fedora/releases/22/Everything/x86_64/os/... http://download1.rpmfusion.org/free/fedora/releases/22/Everything/x86_64/os/...
really that simple, no dealing with runtime linker search paths, additional rpm dependencies or anything like that.
ok I admit, in the long run, maybe it is planless, however this is not intended as a complete solution intended to work forever, it will get you up and running now and will probably keep working in the future but as listed above it is not a repo sysyem with dnf/yum updates and there will come a day when dependencies mismatch but... c'est la vie.
Allegedly, on or about 10 January 2016, Philip Brown sent:
however, in a couple of very simple steps, this gives me a very usable multimedia system on my default fedora workstation without having to install any additional repos. which for me is awesome.
and I can confirm all I had to do was download and extract .so files from the following 2 rpms: http://download1.rpmfusion.org/free/fedora/releases/22/Everything/x86_64/os/... http://download1.rpmfusion.org/free/fedora/releases/22/Everything/x86_64/os/...
really that simple, no dealing with runtime linker search paths, additional rpm dependencies or anything like that.
ok I admit, in the long run, maybe it is planless, however this is not intended as a complete solution intended to work forever, it will get you up and running now and will probably keep working in the future but as listed above it is not a repo sysyem with dnf/yum updates and there will come a day when dependencies mismatch but... c'est la vie.
That's all very well, if you never intend to do a yum update again, in the future. But if you do, then you've got to deal with all the breakage that ensues. Which is going to be more work than simply installing the repo, and installing the files you need, letting the system do the work for you.
You have files that are there, but the system doesn't know about. So installing any more programs that want them, are going to fail and want to install those files. Then you start painting yourself into corner and doing forced installs.
For reasons like that, shoehorning things in is bad advice to give on a general user forum. Especially without full warning, and when it's really not needed. They're already packaged to be installed in the normal way. It's not like you're trying to install some obscure thing that's not available.
On 11 January 2016 at 01:35, Tim ignored_mailbox@yahoo.com.au wrote:
Allegedly, on or about 10 January 2016, Philip Brown sent:
however, in a couple of very simple steps, this gives me a very usable multimedia system on my default fedora workstation without having to install any additional repos. which for me is awesome.
and I can confirm all I had to do was download and extract .so files from the following 2 rpms: http://download1.rpmfusion.org/free/fedora/releases/22/Everything/x86_64/os/... http://download1.rpmfusion.org/free/fedora/releases/22/Everything/x86_64/os/...
really that simple, no dealing with runtime linker search paths, additional rpm dependencies or anything like that.
ok I admit, in the long run, maybe it is planless, however this is not intended as a complete solution intended to work forever, it will get you up and running now and will probably keep working in the future but as listed above it is not a repo sysyem with dnf/yum updates and there will come a day when dependencies mismatch but... c'est la vie.
That's all very well, if you never intend to do a yum update again, in the future. But if you do, then you've got to deal with all the breakage that ensues. Which is going to be more work than simply installing the repo, and installing the files you need, letting the system do the work for you.
Yes, this is why I don't see any benefit to this approach at all. You have to manually download the right rpms, extract libraries, move them into place and then they'll stop working if you ever update the installed programs. On top of which codecs are a great target for vulnerabilities, so worth keeping them up to date. To me this seems much more work than installing the rpmfusion repo, which involves clicking two links at http://rpmfusion.org/, and you get a less reliable setup out of it. The rpmfusion guys do a great job and it integrates with the fedora repos, many of the people there are also fedora project packagers. Particularly over things like gstreamer where the plugins provided will work with fedora gstreamer directly.
On Mon, 2016-01-11 at 10:48 +0000, Ian Malone wrote:
On 11 January 2016 at 01:35, Tim ignored_mailbox@yahoo.com.au wrote:
Allegedly, on or about 10 January 2016, Philip Brown sent:
however, in a couple of very simple steps, this gives me a very usable multimedia system on my default fedora workstation without having to install any additional repos. which for me is awesome.
and I can confirm all I had to do was download and extract .so files from the following 2 rpms: http://download1.rpmfusion.org/free/fedora/releases/22/Everything /x86_64/os/repoview/gstreamer1-libav.html http://download1.rpmfusion.org/free/fedora/releases/22/Everything /x86_64/os/repoview/gstreamer-plugins-ugly.html
really that simple, no dealing with runtime linker search paths, additional rpm dependencies or anything like that.
ok I admit, in the long run, maybe it is planless, however this is not intended as a complete solution intended to work forever, it will get you up and running now and will probably keep working in the future but as listed above it is not a repo sysyem with dnf/yum updates and there will come a day when dependencies mismatch but... c'est la vie.
That's all very well, if you never intend to do a yum update again, in the future. But if you do, then you've got to deal with all the breakage that ensues. Which is going to be more work than simply installing the repo, and installing the files you need, letting the system do the work for you.
Yes, this is why I don't see any benefit to this approach at all. You have to manually download the right rpms, extract libraries, move them into place and then they'll stop working if you ever update the installed programs. On top of which codecs are a great target for vulnerabilities, so worth keeping them up to date. To me this seems much more work than installing the rpmfusion repo, which involves clicking two links at http://rpmfusion.org/, and you get a less reliable setup out of it. The rpmfusion guys do a great job and it integrates with the fedora repos, many of the people there are also fedora project packagers. Particularly over things like gstreamer where the plugins provided will work with fedora gstreamer directly.
+1
poc
On 01/11/2016 11:48 AM, Ian Malone wrote:
On 11 January 2016 at 01:35, Tim ignored_mailbox@yahoo.com.au wrote:
Allegedly, on or about 10 January 2016, Philip Brown sent:
however, in a couple of very simple steps, this gives me a very usable multimedia system on my default fedora workstation without having to install any additional repos. which for me is awesome.
and I can confirm all I had to do was download and extract .so files from the following 2 rpms: http://download1.rpmfusion.org/free/fedora/releases/22/Everything/x86_64/os/... http://download1.rpmfusion.org/free/fedora/releases/22/Everything/x86_64/os/...
really that simple, no dealing with runtime linker search paths, additional rpm dependencies or anything like that.
ok I admit, in the long run, maybe it is planless, however this is not intended as a complete solution intended to work forever, it will get you up and running now and will probably keep working in the future but as listed above it is not a repo sysyem with dnf/yum updates and there will come a day when dependencies mismatch but... c'est la vie.
That's all very well, if you never intend to do a yum update again, in the future. But if you do, then you've got to deal with all the breakage that ensues. Which is going to be more work than simply installing the repo, and installing the files you need, letting the system do the work for you.
Yes, this is why I don't see any benefit to this approach at all. You have to manually download the right rpms, extract libraries, move them into place and then they'll stop working if you ever update the installed programs. On top of which codecs are a great target for vulnerabilities, so worth keeping them up to date. To me this seems much more work than installing the rpmfusion repo, which involves clicking two links at http://rpmfusion.org/, and you get a less reliable setup out of it. The rpmfusion guys do a great job and it integrates with the fedora repos, many of the people there are also fedora project packagers. Particularly over things like gstreamer where the plugins provided will work with fedora gstreamer directly.
never be able to run yum again????? I have been running this workaround for close to a year and dnf/yum is still fully operational. I am merely placing a few library files in my home folder. pray tell, how is this going to blow up my system???
i understand you have nothing against the RPMFusion system and therefore there would be absolutely no benefit for you. however the poster whom I replied to, like me, had concerns and this is simply my workaround.
On 11 January 2016 at 11:42, Philip Brown philip.brown@kiwienglish.es wrote:
On 01/11/2016 11:48 AM, Ian Malone wrote:
On 11 January 2016 at 01:35, Tim ignored_mailbox@yahoo.com.au wrote:
Allegedly, on or about 10 January 2016, Philip Brown sent:
however, in a couple of very simple steps, this gives me a very usable multimedia system on my default fedora workstation without having to install any additional repos. which for me is awesome.
and I can confirm all I had to do was download and extract .so files from the following 2 rpms:
http://download1.rpmfusion.org/free/fedora/releases/22/Everything/x86_64/os/...
http://download1.rpmfusion.org/free/fedora/releases/22/Everything/x86_64/os/...
really that simple, no dealing with runtime linker search paths, additional rpm dependencies or anything like that.
ok I admit, in the long run, maybe it is planless, however this is not intended as a complete solution intended to work forever, it will get you up and running now and will probably keep working in the future but as listed above it is not a repo sysyem with dnf/yum updates and there will come a day when dependencies mismatch but... c'est la vie.
That's all very well, if you never intend to do a yum update again, in the future. But if you do, then you've got to deal with all the breakage that ensues. Which is going to be more work than simply installing the repo, and installing the files you need, letting the system do the work for you.
Yes, this is why I don't see any benefit to this approach at all. You have to manually download the right rpms, extract libraries, move them into place and then they'll stop working if you ever update the installed programs. On top of which codecs are a great target for vulnerabilities, so worth keeping them up to date. To me this seems much more work than installing the rpmfusion repo, which involves clicking two links at http://rpmfusion.org/, and you get a less reliable setup out of it. The rpmfusion guys do a great job and it integrates with the fedora repos, many of the people there are also fedora project packagers. Particularly over things like gstreamer where the plugins provided will work with fedora gstreamer directly.
never be able to run yum again????? I have been running this workaround for close to a year and dnf/yum is still fully operational. I am merely placing a few library files in my home folder. pray tell, how is this going to blow up my system???
Not what I said.
i understand you have nothing against the RPMFusion system and therefore there would be absolutely no benefit for you. however the poster whom I replied to, like me, had concerns and this is simply my workaround.
What is your concern about RPMFusion? You seem to imply you have something against it.
On 01/11/2016 01:21 PM, Ian Malone wrote:
On 11 January 2016 at 11:42, Philip Brown philip.brown@kiwienglish.es wrote:
On 01/11/2016 11:48 AM, Ian Malone wrote:
On 11 January 2016 at 01:35, Tim ignored_mailbox@yahoo.com.au wrote:
Allegedly, on or about 10 January 2016, Philip Brown sent:
however, in a couple of very simple steps, this gives me a very usable multimedia system on my default fedora workstation without having to install any additional repos. which for me is awesome.
and I can confirm all I had to do was download and extract .so files from the following 2 rpms:
http://download1.rpmfusion.org/free/fedora/releases/22/Everything/x86_64/os/...
http://download1.rpmfusion.org/free/fedora/releases/22/Everything/x86_64/os/...
really that simple, no dealing with runtime linker search paths, additional rpm dependencies or anything like that.
ok I admit, in the long run, maybe it is planless, however this is not intended as a complete solution intended to work forever, it will get you up and running now and will probably keep working in the future but as listed above it is not a repo sysyem with dnf/yum updates and there will come a day when dependencies mismatch but... c'est la vie.
That's all very well, if you never intend to do a yum update again, in the future. But if you do, then you've got to deal with all the breakage that ensues. Which is going to be more work than simply installing the repo, and installing the files you need, letting the system do the work for you.
Yes, this is why I don't see any benefit to this approach at all. You have to manually download the right rpms, extract libraries, move them into place and then they'll stop working if you ever update the installed programs. On top of which codecs are a great target for vulnerabilities, so worth keeping them up to date. To me this seems much more work than installing the rpmfusion repo, which involves clicking two links at http://rpmfusion.org/, and you get a less reliable setup out of it. The rpmfusion guys do a great job and it integrates with the fedora repos, many of the people there are also fedora project packagers. Particularly over things like gstreamer where the plugins provided will work with fedora gstreamer directly.
never be able to run yum again????? I have been running this workaround for close to a year and dnf/yum is still fully operational. I am merely placing a few library files in my home folder. pray tell, how is this going to blow up my system???
Not what I said.
that is reassuring =)
i understand you have nothing against the RPMFusion system and therefore there would be absolutely no benefit for you. however the poster whom I replied to, like me, had concerns and this is simply my workaround.
What is your concern about RPMFusion? You seem to imply you have something against it.
bad past experience, could have been livna, it was a long time ago and I never used it since. I imagine it should be a lot better now, however seeing as I only need these few files I prefer just to download them rather than having an extra repo system. The updates for these rpms are few and far between (last updates were Sept 2014 and May 2015) so it does not really add much to my workload.
On Mon, 11 Jan 2016 14:11:13 +0100, Philip Brown wrote:
What is your concern about RPMFusion? You seem to imply you have something against it.
bad past experience, could have been livna, it was a long time ago and I never used it since. I imagine it should be a lot better now, however seeing as I only need these few files I prefer just to download them rather than having an extra repo system. The updates for these rpms are few and far between (last updates were Sept 2014 and May 2015) so it does not really add much to my workload.
But you download the files from them nevertheless?
Wouldn't it be much more convenient to turn off the repo after installing the needed packages? That way you will benefit from dependency checks during normal updates of your installation. And you can one-shot re-enable the repo any time to check whether there are updates for those few packages you want. The --enablerepo= option for Yum and DNF exists for such usage patterns.
Allegedly, on or about 11 January 2016, Philip Brown sent:
bad past experience, could have been livna, it was a long time ago and I never used it since. I imagine it should be a lot better now, however seeing as I only need these few files I prefer just to download them rather than having an extra repo system. The updates for these rpms are few and far between (last updates were Sept 2014 and May 2015) so it does not really add much to my workload.
Kinda hard to relate ancient experience to what might happen now, one doesn't necessarily demand the other.
But still, there are easier and better ways to do it than force hand-unpacked files from an archive onto a system. Such as:
Download the few rpm files that concern you, then use yum localinstall with those files (or dnf).
They're installed properly, then. And if other files are needed at the same time, yum will get them, too. The files are in the database so that other things are aware of their presence. And they're easily removed, without breaking other things.
It's just not a good idea to jam in files. It's an even worse idea to advise someone to do it. More so if it's not given with full warning.
On 01/11/2016 05:35 PM, Tim wrote:
Allegedly, on or about 11 January 2016, Philip Brown sent:
bad past experience, could have been livna, it was a long time ago and I never used it since. I imagine it should be a lot better now, however seeing as I only need these few files I prefer just to download them rather than having an extra repo system. The updates for these rpms are few and far between (last updates were Sept 2014 and May 2015) so it does not really add much to my workload.
Kinda hard to relate ancient experience to what might happen now, one doesn't necessarily demand the other.
But still, there are easier and better ways to do it than force hand-unpacked files from an archive onto a system. Such as:
Download the few rpm files that concern you, then use yum localinstall with those files (or dnf).
They're installed properly, then. And if other files are needed at the same time, yum will get them, too. The files are in the database so that other things are aware of their presence. And they're easily removed, without breaking other things.
thanks, I appreciate the alternative method you have given. I will try that before going the "install repo" route if my setup breaks.
It's just not a good idea to jam in files. It's an even worse idea to advise someone to do it. More so if it's not given with full warning.
On Mon, 2016-01-11 at 17:59 +0100, Philip Brown wrote:
They're installed properly, then. And if other files are needed at
the
same time, yum will get them, too. The files are in the database
so
that other things are aware of their presence. And they're easily removed, without breaking other things.
thanks, I appreciate the alternative method you have given. I will try that before going the "install repo" route if my setup breaks.
You can also have the repo file installed but disabled, but use "yum (or dnf) --enablerepo ..." when you want to install something specific.
poc
On Sun, 10 Jan 2016 23:43:38 +0100, Philip Brown wrote:
And a "dnf install gstreamer1-plugins*" here wants to install "35 Packages", while some dependencies probably are installed already.
Ok Michael, I can see you don't like this.
however, in a couple of very simple steps, this gives me a very usable multimedia system on my default fedora workstation without having to install any additional repos. which for me is awesome.
and I can confirm all I had to do was download and extract .so files from the following 2 rpms: http://download1.rpmfusion.org/free/fedora/releases/22/Everything/x86_64/os/... http://download1.rpmfusion.org/free/fedora/releases/22/Everything/x86_64/os/...
That doesn't make it much better, since it mixes plugins for GStreamer 0.10.x and GStreamer 1.x, and applications based on either one don't support the other one.
And while you would get less plugins, if installing only the stuff from those two rpms, there still is a dependency on two external packages. If "libmad" for MP3 decoding is not installed already, the GStreamer plugin using it would not work at all:
# dnf install gstreamer1-libav gstreamer-plugins-ugly Dependencies resolved. ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: gstreamer-plugins-ugly x86_64 0.10.19-18.fc23 rpmfusion-free-updates-testing 333 k gstreamer1-libav x86_64 1.6.2-1.fc23 rpmfusion-free-updates-testing 230 k libmad x86_64 0.15.1b-17.fc23 rpmfusion-free-updates-testing 78 k opencore-amr x86_64 0.1.3-4.fc22 rpmfusion-free 178 k
Transaction Summary ================================================================================ Install 4 Packages
Total download size: 819 k Installed size: 2.0 M Is this ok [y/N]:
really that simple, no dealing with runtime linker search paths, additional rpm dependencies or anything like that.
Wrong. As shown above. You would need to extract the "libmad" shared lib and all other runtime dependencies in a similar way to decouple it from the RPM based system installation. Or else any package update could replace libmad with an upgrade that's incompatible with the plugins you've extracted.
On 01/11/2016 03:40 PM, Michael Schwendt wrote:
On Sun, 10 Jan 2016 23:43:38 +0100, Philip Brown wrote:
And a "dnf install gstreamer1-plugins*" here wants to install "35 Packages", while some dependencies probably are installed already.
Ok Michael, I can see you don't like this.
however, in a couple of very simple steps, this gives me a very usable multimedia system on my default fedora workstation without having to install any additional repos. which for me is awesome.
and I can confirm all I had to do was download and extract .so files from the following 2 rpms: http://download1.rpmfusion.org/free/fedora/releases/22/Everything/x86_64/os/... http://download1.rpmfusion.org/free/fedora/releases/22/Everything/x86_64/os/...
That doesn't make it much better, since it mixes plugins for GStreamer 0.10.x and GStreamer 1.x, and applications based on either one don't support the other one.
And while you would get less plugins, if installing only the stuff from those two rpms, there still is a dependency on two external packages. If "libmad" for MP3 decoding is not installed already, the GStreamer plugin using it would not work at all:
# dnf install gstreamer1-libav gstreamer-plugins-ugly Dependencies resolved. ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: gstreamer-plugins-ugly x86_64 0.10.19-18.fc23 rpmfusion-free-updates-testing 333 k gstreamer1-libav x86_64 1.6.2-1.fc23 rpmfusion-free-updates-testing 230 k libmad x86_64 0.15.1b-17.fc23 rpmfusion-free-updates-testing 78 k opencore-amr x86_64 0.1.3-4.fc22 rpmfusion-free 178 k
Transaction Summary
Install 4 Packages
Total download size: 819 k Installed size: 2.0 M Is this ok [y/N]:
really that simple, no dealing with runtime linker search paths, additional rpm dependencies or anything like that.
Wrong. As shown above. You would need to extract the "libmad" shared lib and all other runtime dependencies in a similar way to decouple it from the RPM based system installation. Or else any package update could replace libmad with an upgrade that's incompatible with the plugins you've extracted.
thanks for explaining this so clearly, I now understand. If libmad and/or opencore-amr from the standard repos are upgraded to where they are incompatible I will certainly try out RPMFusion.
On Sun, Jan 10, 2016 at 4:41 PM, Michael Schwendt mschwendt@gmail.com wrote:
And a "dnf install gstreamer1-plugins*" here wants to install "35 Packages", while some dependencies probably are installed already.
That's why I mentioned mpg123 earlier in the thread. Most mp3 players in the Linux world require a mess of dependencies.
Call me old fashioned, but I prefer a static, single binary to perform a simple task like playing a mp3 file - you know, the Unix way, do one thing and do it self-cointained.
When I've the time, I''ll put up a site just to provide statically linked builds of tools like mpg123 (if needed, I'm not sure it needs any dependencies or external libs), one I can run even while booting from a LiveCD without messing with dnf or having to touch the dnf databases (which, as you know, is time consuming on the initial run).
The more I think it, the more sense http://sta.li/ makes. :-p FC
Allegedly, on or about 11 January 2016, Fernando Cassia sent:
Call me old fashioned, but I prefer a static, single binary to perform a simple task like playing a mp3 file - you know, the Unix way, do one thing and do it self-cointained.
There's some logic to that, but all some illogic. Would you have yet another binary program to play wav files, another for oggs, another for flac, and have to call the right one for each audio file you want to play? Or would you use the one player for any type of audio file, and let it make use of the appropriate codec for the file?
The idea of having a common codec for handling, say mp3 files, has merit in itself, along the lines you're promoting for the binary player. If half a dozen programs all use the same codec file, that's more people debugging and improving a codec.
Personally, I think that there's far too many different types of media file to have a single binary player that handles them all. There would be poorly supported ones that coders didn't really place much priority on. And I certainly wouldn't want to have to use a plethora of different binary players for each different audio filetype.
On 11 January 2016 at 16:41, Tim ignored_mailbox@yahoo.com.au wrote:
Allegedly, on or about 11 January 2016, Fernando Cassia sent:
Call me old fashioned, but I prefer a static, single binary to perform a simple task like playing a mp3 file - you know, the Unix way, do one thing and do it self-cointained.
There's some logic to that, but all some illogic. Would you have yet another binary program to play wav files, another for oggs, another for flac, and have to call the right one for each audio file you want to play? Or would you use the one player for any type of audio file, and let it make use of the appropriate codec for the file?
The idea of having a common codec for handling, say mp3 files, has merit in itself, along the lines you're promoting for the binary player. If half a dozen programs all use the same codec file, that's more people debugging and improving a codec.
Personally, I think that there's far too many different types of media file to have a single binary player that handles them all. There would be poorly supported ones that coders didn't really place much priority on. And I certainly wouldn't want to have to use a plethora of different binary players for each different audio filetype.
This is sort of what plugin architectures try to do too (like gstreamer). The trick is having an interface that can handle the required data while the application is able to look for the presence of the component it needs for a particular data type. That can be done with plugins or binaries (see applications like grip which use separate tools to do encoding). It does take more work, because you need a framework that can handle that discovery (rather than just statically link in every needed library, even handing off to the different demuxing and decoding algorithms is harder than a tool that works with a single format), and to fill in any gaps in the formats that are supported through that interface. The result is applications that use those frameworks end up more complex and have to wait for the framework to move before they can support new things, while lightweight tools can move more quickly, but end up becoming non-lightweight tools in the process. I think this is why new 'minimalist' players appear every so often.
And of course every shiny new video codec starts off supported in one particular implementation and needs to be taken up by the others (even before you bring in patent issues).
On Mon, Jan 11, 2016 at 1:47 PM, Ian Malone ibmalone@gmail.com wrote:
There's some logic to that, but all some illogic. Would you have yet another binary program to play wav files, another for oggs, another for flac, and have to call the right one for each audio file you want to play? Or would you use the one player for any type of audio file, and let it make use of the appropriate codec for the file?
Well, "the Unix way" is you have programs that send everything to standard output, then redirect as needed by other apps.
Of course that doesn't prevent other, "big" players like VLC implementing their own codecs, internally, if devs feels the need or competent enought to maintain them...
FC
On Tue, 12 Jan 2016 08:02:59 -0500, Fernando Cassia wrote:
Well, "the Unix way" is you have programs that send everything to standard output, then redirect as needed by other apps.
Which would get funny, if you wanted to seek back and forth in a large chunk of data fed to a program via stdin, such as when searching for ID3 tags in an MP3 file.
On Tue, Jan 12, 2016 at 8:24 AM, Michael Schwendt mschwendt@gmail.com wrote:
Which would get funny, if you wanted to seek back and forth in a large chunk of data fed to a program via stdin, such as when searching for ID3 tags in an MP3 file.
Which gets back to my point, that doesn't prevent big media players from implementing their own codecs, internally.
Does Gnome/Nautilus mean that there is no place for the command line "tar" command? or 'unzip' ?
FC
On 12 January 2016 at 13:39, Fernando Cassia fcassia@gmail.com wrote:
On Tue, Jan 12, 2016 at 8:24 AM, Michael Schwendt mschwendt@gmail.com wrote:
Which would get funny, if you wanted to seek back and forth in a large chunk of data fed to a program via stdin, such as when searching for ID3 tags in an MP3 file.
Which gets back to my point, that doesn't prevent big media players from implementing their own codecs, internally.
Does Gnome/Nautilus mean that there is no place for the command line "tar" command? or 'unzip' ?
Of course not. However "the Unix way", while very powerful in certain contexts, doesn't work at all well for interactive use, or tasks that require communication between multiple data sources. There are command line encoders / decoders for many codecs. For some that does mean you have to wrangle with something like mencoder and worry about things like transport mechanisms. Which is the first thing you notice when dealing with anything more complex than mp3, mp3 itself mixes the transport and encoding, which makes it fairly simple to deal with. Actually, the various ID3 tags that Michael refers to are separate binary blocks bunged on at the end. Reading as a stream you can't actually access those, for example to display while playing, until *after* you've had all the audio data.
To be stricly consistent with "the Unix way" (which has never really been the only way of doing things under Unix, but a convenient way of handling data that can be processed in a stream), you would have to stream the output of the decoder to the sound device too, probably via sox to convert the sample format (and possibly resample the frequency). Want to play back something that has a different sampling rate to your soundcard's default? You have to force resampling, because otherwise you'd have to communicate and negotiate sample rates out-of-channel. Similarly searching within a stream isn't allowed, because anything except a fixed bitrate input (which is very few audio codecs and almost no compressed video ones) requires the demuxer to be able to search through the input file (more trivially, going backwards is obviously not possible).
Allegedly, on or about 12 January 2016, Ian Malone sent:
Actually, the various ID3 tags that Michael refers to are separate binary blocks bunged on at the end.
That can't be the only place they're put. For instance, you can stream audio using MP3 compression, and see metadata as it streams.
On Tue, Jan 12, 2016 at 10:07 AM, Tim ignored_mailbox@yahoo.com.au wrote:
That can't be the only place they're put.
The ID3 info is put at the end of MP3 files, that is per design. (Actually, a clever hack, so mp3 player that don't know anything about id3 could still play the files).
FC
On Tue, 12 Jan 2016 10:28:33 -0500, Fernando Cassia wrote:
The ID3 info is put at the end of MP3 files, that is per design.
Only ID3v1. Unless you're stuck in history, ID3v2 is current and found in most MP3 files. Normally, it's prepended to files as a header, but can also be appended to files again. In v2.4 or so.
Tim:
That can't be the only place they're put.
Fernando Cassia:
The ID3 info is put at the end of MP3 files, that is per design. (Actually, a clever hack, so mp3 player that don't know anything about id3 could still play the files).
But I've listened to radio streams using MP3 encoding, and it's had data about what's on while it's on, not after.
On 13 January 2016 at 06:58, Tim ignored_mailbox@yahoo.com.au wrote:
Tim:
That can't be the only place they're put.
Fernando Cassia:
The ID3 info is put at the end of MP3 files, that is per design. (Actually, a clever hack, so mp3 player that don't know anything about id3 could still play the files).
But I've listened to radio streams using MP3 encoding, and it's had data about what's on while it's on, not after.
Various ways this can be done, ID3v2 goes at the start for this purpose (though later versions can be put at the end too, just to be confusing). But it can also be communicated out of channel, e.g. https://forums.radiotoolbox.com/viewtopic.php?t=74 "Client to server" and "meta title streaming", shoutcast provides titles in the returned request header, it also includes metadata at intervals (and the header says what intervals, at least that's my understanding). In both cases the method is negotiated between client and server, to avoid tripping up clients that don't understand this information.
On Tue, Jan 12, 2016 at 8:24 AM, Michael Schwendt mschwendt@gmail.com wrote:
such as when searching for ID3 tags in an MP3 file.
You could also use gnu 'tail' part of gnu textutils -I believe it's now called coreutils-, to get the last 'n' bytes of a file, and there's your ID3 info...
FC
On 12 January 2016 at 13:40, Fernando Cassia fcassia@gmail.com wrote:
On Tue, Jan 12, 2016 at 8:24 AM, Michael Schwendt mschwendt@gmail.com wrote:
such as when searching for ID3 tags in an MP3 file.
You could also use gnu 'tail' part of gnu textutils -I believe it's now called coreutils-, to get the last 'n' bytes of a file, and there's your ID3 info...
Well, you'd use id3info, because the id3v2 tag is not guaranteed to be a particular length and may also contain binary information. But, correct tool aside, the more relevant point is this information is not actually available to a player that is playing this as an input stream until the complete stream has been received. If you want to do that you have to cheat and cache everything before you start playback. Or, in more general terms, doing anything non-linear with multimedia information is very difficult to handle in a streamed manner.
On Tue, Jan 12, 2016 at 9:21 AM, Ian Malone ibmalone@gmail.com wrote:
If you want to do that you have to cheat and cache everything before you start playback. Or, in more general terms, doing anything non-linear with multimedia information is very difficult to handle in a streamed manner
No. I never said I wanted to "stream" anything. I wanted to play a local mp3 file sitting on my hard drive, to the default speakers. Mpg123 serves that purpose. And as it fits the bill of "the unix way" (a simle, self-contained tool doing a single thing and doing it efficiently),IMHO it should be part of the standard toolset. That was my reasoning and I stick with that.
Now, if we drift the topic to "how to do a mp3 player" I bet I could design a player using mpg123 and standard command line gnu tools that performs much faster than one relying on the tons of smegma that come along Gstreamer + GUI toolkits that Gnome/KDE multimedia APIs.
What you call "cheating" (pre-loading the id3 info before loading every song instead of loading the whole file into ram, seeking to the end, and extracting the id3 info as each file is played) is actually efficient design, in my book.
Btw: id3 info could be obtained by using the http feature of requesting part of a file(*), by first obtaining the file size, closing the connection, then requesting the last "x" bytes (total file size - id3), that way you get your Id3 over "streaming" before requesting the whole file. :)
FC (*) http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
On 12 January 2016 at 14:31, Fernando Cassia fcassia@gmail.com wrote:
On Tue, Jan 12, 2016 at 9:21 AM, Ian Malone ibmalone@gmail.com wrote:
If you want to do that you have to cheat and cache everything before you start playback. Or, in more general terms, doing anything non-linear with multimedia information is very difficult to handle in a streamed manner
No. I never said I wanted to "stream" anything. I wanted to play a local mp3 file sitting on my hard drive, to the default speakers. Mpg123 serves that purpose. And as it fits the bill of "the unix way" (a simle, self-contained tool doing a single thing and doing it efficiently),IMHO it should be part of the standard toolset. That was my reasoning and I stick with that.
By stream I mean pipe in this context, a single data stream, which is what people typically mean when they talk about "the unix way", where separate processing steps can be chained together. Of course since there isn't one Unix way people can mean lots of different things.
Now, if we drift the topic to "how to do a mp3 player" I bet I could design a player using mpg123 and standard command line gnu tools that performs much faster than one relying on the tons of smegma that come along Gstreamer + GUI toolkits that Gnome/KDE multimedia APIs.
Of course you could, it's called mpg123. It has terminal controls, you don't really need to add tar, awk or cpio to it to make it work. Now let's see it support wav, Vorbis, Opus and AAC.
What you call "cheating" (pre-loading the id3 info before loading every song instead of loading the whole file into ram, seeking to the end, and extracting the id3 info as each file is played) is actually efficient design, in my book.
It is cheating insofar as it does not work in a single data pipe without caching the entire stream, which doesn't scale well for long streams.
Btw: id3 info could be obtained by using the http feature of requesting part of a file(*), by first obtaining the file size, closing the connection, then requesting the last "x" bytes (total file size - id3), that way you get your Id3 over "streaming" before requesting the whole file. :)
You are proposing having an http server in the way as *simpler*? Anyway, again, id3 tag lengths are not fixed.
Media players do not fit well into the 'simple tool does one thing to a file' model because they are always expected to do other things. An interactive command line tool like mpg123 is already well beyond the simple single data stream in single data stream out model.
On Tue, Jan 12, 2016 at 10:59 AM, Ian Malone ibmalone@gmail.com wrote:
You are proposing having an http server in the way as *simpler*? Anyway, again, id3 tag lengths are not fixed.
don't twist my words, Ian.
I introduced a web server into the argument that you can't get id3 tags with a single tool, and you used the word "stream" by which I thought you mean music streaming from a web site (web server).
So you CAN extract id3 data from mp3 files, whether locally (by using tail or id3tool or anything else) before loading the entire file. That was my point.
And most MP3 files have ID3v1, not id3v2. ID3 v1 is fixed length @ 128 bytes.
ID3v2, on the other hand, is added at the start of the file. So you can check the last 128 bytes of the file to see if it's got ID3v1, and if not, check for ID3v2 at the start...
FC
On 12 January 2016 at 16:17, Fernando Cassia fcassia@gmail.com wrote:
On Tue, Jan 12, 2016 at 10:59 AM, Ian Malone ibmalone@gmail.com wrote:
You are proposing having an http server in the way as *simpler*? Anyway, again, id3 tag lengths are not fixed.
don't twist my words, Ian.
I introduced a web server into the argument that you can't get id3 tags with a single tool, and you used the word "stream" by which I thought you mean music streaming from a web site (web server).
So you CAN extract id3 data from mp3 files, whether locally (by using tail or id3tool or anything else) before loading the entire file. That was my point.
And most MP3 files have ID3v1, not id3v2. ID3 v1 is fixed length @ 128 bytes.
Where do I say anything else? Why are we on this bizarre sidetrack about whether you can use tail to get id3 information? You're already proposing effectively rebuilding id3info just because *part* of its job can be done with text handling tools in some, but not all cases. That is crazy and pointless. id3info is exactly the minimalist tool to do this job and handle all the corner cases.
ID3v2, on the other hand, is added at the start of the file. So you can check the last 128 bytes of the file to see if it's got ID3v1, and if not, check for ID3v2 at the start...
My point is still that you are scanning the whole file to do this. The simple model for command line utilities that can be chained together requires that a file argument can be replaced by stdin/stdout, which for this case it cannot without taking liberties about what that means. If I do xzcat < somefile > somefile.xz, data gets written as it gets processed, we don't have to read and cache the whole of somefile first.
Of course you can have single tools that act on files to get well defined information. But while it's a useful model it doesn't work well in all situations.
On Tue, Jan 12, 2016 at 1:01 PM, Ian Malone ibmalone@gmail.com wrote:
Of course you can have single tools that act on files to get well defined information. But while it's a useful model it doesn't work well in all situations.
All I wanted was mpg123 so I could play a darn mp3 file. ;) KDE/Gnome wizards can code their brains out until it required a 4-core 4Ghz CPU to play a mp3 file, but I'd stick with mpg123 which worked well since the days of the AMD K6-III 450 Mhz ;)
FC
On 12 January 2016 at 21:34, Fernando Cassia fcassia@gmail.com wrote:
On Tue, Jan 12, 2016 at 1:01 PM, Ian Malone ibmalone@gmail.com wrote:
Of course you can have single tools that act on files to get well defined information. But while it's a useful model it doesn't work well in all situations.
All I wanted was mpg123 so I could play a darn mp3 file. ;) KDE/Gnome wizards can code their brains out until it required a 4-core 4Ghz CPU to play a mp3 file, but I'd stick with mpg123 which worked well since the days of the AMD K6-III 450 Mhz ;)
Peace.
On Tue, Jan 12, 2016 at 1:01 PM, Ian Malone ibmalone@gmail.com wrote:
Why are we on this bizarre sidetrack about whether you can use tail to get id3 information?
I don't know. ;) You implied that the Unix way was not appropiate for multimedia content, I said you could use text mode utils just fine, and that finding the id3 info could still be done by a text-mode self-contained player beforehand, by calling other tools that extracted such info and displayed it, before even loading the mp3 file for playback.
That's it.
While interesting as a technical/philosophical discussion, I think it's time to put this thread to rest, as far as I'm concerned. Thanks to all who contibuted. :)
FC
On Sat, 9 Jan 2016 10:41:21 -0500, Fernando Cassia wrote:
Is there any side-effect from enabling the rpmfusion repos? Conflict with system libs?
http://rpmfusion.org/FAQ#How_can_I_trust_that_RPM_Fusion_will_work_with_the_...
On Sat, Jan 9, 2016 at 4:50 AM, Fernando Cassia fcassia@gmail.com wrote:
and that only MP3 *encoding* was actively pursued by the Fraunhoffer Insitute and assorted MP3 cartels.
MP3 encoding is indeed what Fraunhofer IIS has primarily focused on in the past. The problem is that the decoding technology is also patented [1]. I believe all of the major MP3 patents have expired in the European Union, but in the United States, the last of the patents will not expire until December 30, 2017.
The problem is that Fraunhofer IIS has gone after MP3 decoding software in the past [2]. While they haven't recently attempted litigation against MP3 decoders (to my knowledge), LGPL software like mpg123 is in violation of its license by infringing upon a patent [3].
The problem is that all of this is very open to interpretation (e.g. IBM held a patent for the concept of the progress bar until 2011). When this happens, the simplest solution is to exclude a package or library from the Fedora Project.
I'll direct you to the wonderful Xiph.Org Foundation (home of Vorbis, FLAC, and Theora) as a conclusion [4].
[1] http://mp3licensing.com/help/developers.html#55 [2] https://www.lumendatabase.org/notices/1027 [3] http://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html [4] http://xiph.org/
-
Brandon Vincent -
Doug -
Ed Greshko -
Fernando Cassia -
Ian Malone -
Michael Schwendt -
Patrick O'Callaghan -
Philip Brown -
Sylvia Sánchez -
Tim