mpg123 is available from the rpmfusion repos.

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!

Manjaro includes decoders. But it's Europe based.

On Sat, Jan 9, 2016 at 7:12 AM, Ed Greshko <ed.greshko(a)greshko.com&gt; wrote: > mpg123 is available from the rpmfusion repos. Thanks Ed! Is there any side-effect from enabling the rpmfusion repos? Conflict with system libs?

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(a)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.

yeah, well, that's just, like, your opinion, man.

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 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.

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.

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/... > http://download1.rpmfusion.org/free/fedora/releases/22/Everything/x86_64/... > > 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.

On 11 January 2016 at 01:35, Tim <ignored_mailbox(a)yahoo.com.au&gt; 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/... >> http://download1.rpmfusion.org/free/fedora/releases/22/Everything/x86_64/... >> >> 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 11 January 2016 at 11:42, Philip Brown <philip.brown(a)kiwienglish.es&gt; wrote: > On 01/11/2016 11:48 AM, Ian Malone wrote: >> On 11 January 2016 at 01:35, Tim <ignored_mailbox(a)yahoo.com.au&gt; 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/... >>>> >>>> http://download1.rpmfusion.org/free/fedora/releases/22/Everything/x86_64/... >>>> >>>> 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.

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.

> 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.

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/... > http://download1.rpmfusion.org/free/fedora/releases/22/Everything/x86_64/... > 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.

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?

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.

Actually, the various ID3 tags that Michael refers to are separate binary blocks bunged on at the end.

The ID3 info is put at the end of MP3 files, that is per design.

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 Tue, Jan 12, 2016 at 8:24 AM, Michael Schwendt <mschwendt(a)gmail.com&gt; 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...

On Tue, Jan 12, 2016 at 9:21 AM, Ian Malone <ibmalone(a)gmail.com&gt; 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. :)

On Tue, Jan 12, 2016 at 10:59 AM, Ian Malone <ibmalone(a)gmail.com&gt; 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. http://id3.org/ID3v1

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...

On Tue, Jan 12, 2016 at 1:01 PM, Ian Malone <ibmalone(a)gmail.com&gt; 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 ;)

Is there any side-effect from enabling the rpmfusion repos? Conflict with system libs?