Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add mp3 support #507

Open
m4iler opened this issue Apr 18, 2017 · 32 comments
Open

add mp3 support #507

m4iler opened this issue Apr 18, 2017 · 32 comments
Labels
feature request Issue is related to a feature in the app help wanted Help is wanted in fixing this issue

Comments

@m4iler
Copy link

m4iler commented Apr 18, 2017

  • [ I did ] I carefully read the contribution guidelines and agree to them.
  • [ I did ] I checked if the issue/feature exists in the latest version.

Call me granddaddy McSquare, but now that MP3 is slowly moving from patent to free software, can we expect MP3 support? Not to knock M4A, but my player simply doesn't understand it and the podcasts I frequent are too large to be practical as video when it's just a still image.

Thank you for your answer, love your app! Helps me get off google that little bit more.

@mauriciocolli
Copy link
Contributor

Youtube doesn't offer mp3 direct links, so the only alternative is converting it (we could implement the FFMpeg library, but I don't know when or if it'll ever happen...).

But did you tried the background player of NewPipe?
It uses only the audio stream of the video saving a lot of data, and now that ExoPlayer is implemented (very recently, my PR was merged today), is more stable than ever, I think you should give a try.

@m4iler
Copy link
Author

m4iler commented Apr 19, 2017 via email

@theScrabi
Copy link
Member

theScrabi commented Apr 19, 2017

FFMPEG for Android, huh? Too bad there are no good alternatives on f-droid.

Yea an ffmpeg converter app on fdroid would be a serious and valuable addition to the repo. I'd realy loved to see something like that.

Also having an external app for converting things sounds much more covenient to me than putting ffmpeg (which is a huge thing) into NP.

That sounds interesting:
https://trac.ffmpeg.org/wiki/CompilationGuide/Android

@darkon5
Copy link
Contributor

darkon5 commented Apr 20, 2017

Not to knock M4A, but my player simply doesn't understand it

Android natively supports AAC on M4A containers. Maybe something is wrong with your player?

Source: https://developer.android.com/guide/topics/media/media-formats.html#core

@utack
Copy link

utack commented Apr 22, 2017

@m4iler what happens when you rename the m4a to mp3 or aac manually?
I know this is not a "clean" solution, but that might just force your player to open it and play it
Or grab vanilla from F-Droid

@SkyzohKey
Copy link

Couldn't this be solved by using a webservice to convert the song instead of embeding ffmepg in the app ?

@theScrabi
Copy link
Member

theScrabi commented May 13, 2017

Uch ... than you'd have to upload it to some muddy service.
I don't like this solution.

But we could make someone implement a proper android fronted for ffmpeg.

@ghost
Copy link

ghost commented May 13, 2017 via email

@theScrabi
Copy link
Member

theScrabi commented May 13, 2017

I'd like to have an app that provides ffmpeg, so we could write an interface to that app. So second choice.

@SkyzohKey
Copy link

What about a converter hosted on your, website?

@theScrabi
Copy link
Member

@TheAssassin would kill me, because everything runs on his server.
Also I don't want to make anyone depend on infrastructure I provide.

@utack
Copy link

utack commented May 13, 2017

I still don't believe there is an Android media player out there that does not support ogg/vorbis or aac/m4a
Maybe you just need to trigger the Android Media Scanner after each download, so it shows up?
I think that is usualy only done when USB is connected and disconnected?

@SkyzohKey
Copy link

Good idea, but MP3 allows better ID3 tagging I guess.

@ghost
Copy link

ghost commented May 13, 2017 via email

@TheAssassin
Copy link
Member

There's several issues with this feature proposal. Below I point out most of them.
TL;DR: Bad idea, don't implement it.

  • You don't need a whole ffmpeg bundle to convert stuff to MP3. As ffmpeg doesn't do the conversion itself but uses LAME (patent issues, see below), you need to bundle both. It doesn't make sense to include both then.

  • A hosted converter makes us vulnerable for copyright complaints worldwide. YouTube as a platform deals with this by having contracts with GEMA and their competitors in other countries, or providing a permissive standard license most users use for their uploads.
    Having users download files and convert them on the phones means they are responsible for respecting copyright laws and other regulations themselves though, and if they break copyright, the tools cannot be made responsible, at least in most countries. This protects us very well at the moment.
    If we offered a hosted version, we would be responsible ourselves personally though, meaning that the single devs might be sued at any time. I don't want to take that risk, and can not recommend anyone to host such platforms.
    (For example, even conversion of stuff licensed under CC-*-ND potentially breaks the license.)

  • A client conversion solution might be really slow, depending on the hardware and the codec in use. But as performance gets better, I wouldn't care about that too much.

  • There are several patents on parts of MP3 coding held by Fraunhofer IIS, Technicolor and other companies (same goes for AAC etc., only free codecs like Vorbis are not affected by that). I believe that most devices sold (like laptops, phones etc.) do have a valid license for MP3 and other codecs as the device vendors have to acquire them anyway so that using stuff like the Android media player is legal for the users. Though, I'm not a lawyer, you shouldn't rely on my words at all, but I'd be worried anyway if I were you. LAME FAQ contains a paragraph on that, too, that is worth reading. You might have to investigate the patent situation thoroughly for newer codecs, MP3 patents' validity should time out around 2017 and/or 2018 anyway, but for example AAC is way younger.

But the most meaningful argument that I can come up with to prevent you from implementing it is the following.

Downloads of copyrighted material are usually not prosecuted as there's too many of them and it's not really worth the effort. But as soon as you change the material, it can get dangerous.

E.g., you convert a file, the converter puts some information on who did it into the file (yes, that's happened in the past with some "freeware" (maybe they wanted to track their software usage or something), some people have been sued (I'd try to find the link if anyone cares, but it was quite a while ago, even if I wouldn't find it, it's a realistic scenario)). Then, if the people sent it to a friend who sent it to a few friends etc etc, police might somewhen get hands on these files, and try to find the origin. That might cause serious trouble for those people.

Sure, you can blame the users for breaking laws there, but to be honest, most users are quite unexperienced and (sorry, I didn't find another word), naive, and as a software vendor, I'd try to protect my users from such stuff. You shouldn't make them break law even more. Downloading is primarly an issue for YouTube as the hoster, but they are a huge company and can deal with it accordingly. Anything that happens after that is risky.

Us software devs have the responsibility for protecting users from such stuff. Please think about this feature, and try to compare costs and benefits of implementing this. This is just an advice, and I don't want to prevent anyone from implementing it, but primarily make you think about it.

(Side fact: In Germany, it should be fine to save and even convert the files for private use, as they are validly licensed via YouTube and thus can be saved for offline use (it's called "Privatkopie"), as long as you don't share them with anyone (even family users would have to download and thus create their own copy) and use them for private purposes only (e.g. listening to it with friends). But most other countries don't have something like that in their copyright laws. So yeah, try to avoid such stuff.)

But, if the executives of the project consider it more useful than risky (democracy ftw), please don't use MP3 or AAC, use something open such as Vorbis (it's in the list @darkon5 linked to) . They are way less problematic in so many ways, well supported and we should spread the spirit of patent less open-source (and even public domain) code.

@utack
Copy link

utack commented May 13, 2017

@TheAssassin forgetting the most obvious reason to not implement it:
Lossy to lossy conversion to support some odd legacy music player that can't deal with audio formats introduced almost two decades ago is a major waste of ressources

@TheAssassin
Copy link
Member

I disagree, @utack. Your statement isn't really scientific, please let me explain why that is not an argument against this feature proposal.

First of all, it isn't our decision what people do on their phones. The only waste of resources with pointless conversions could be electric energy and CPU cycles. But it would even save resources on the flash storage of a phone, considering that a file encoded with a lower bitrate (or a more modern encoder) will consume less space. So that argument isn't valid.

Also, lossy to lossy conversion doesn't necessarily decrease the file quality in a way so most people would hear a difference between the files. In fact, most users don't even care much. And in these cases, conversion can make a lot of sense. Also, 320kpbs MP3's quality is pretty good (most DJs use that instead of lossless for example), such files can be converted to other formats without much loss either. So, if you got some high quality files, and just need another format (same quality level), a conversion can make sense, too. Newer codecs can reach a way higher quality with a lower bitrate.

Also, DACs in smartphones are far from high fidelity, so I think you don't really need to think about quality losses due to conversions.

@darkon5
Copy link
Contributor

darkon5 commented May 15, 2017

AAC has been proved to provide better filesize at the same bitrate as MP3 using the latest encoders. And yes, lossy to lossy decreases content quality by a significant margin (MP3 directly cuts above 20 KHz, for example).

IMHO what people want their files to be encoded at is not NewPipe's concern, as it's just a tool to scrap content from Youtube. And Youtube is using AAC for a reason.

Source: I'm a DJ, musician and a huge music collection owner.

PS: You'll never see a DJ who used a MP3 reencoded from a AAC. Only lossless to lossy.

@TheAssassin
Copy link
Member

@darkon5 your statement about less filesize for the same quality is true, but not the way you describe it: the bitrate must be lower for an AAC file to be smaller, like MP3 bitrate > AAC bitrate. This is due to how bitrate is defined: amount of bits per second.

Sure, (real) DJs or audiophile people avoid reencoded files for a reason. But still, for the reasons I pointed out, this argument doesn't really matter for the average smartphone user, because 1) they don't hear the difference and 2) the hardware isn't good enough to hear a difference even between lossless and say, 256 kbit/s MP3.

The psychoacoustic effects that MP3 uses for its perceptual audio coding are lossy, right, but any frequency above 20 kHz cannot be heard anyway by humans (average human being hears up to 16 kHz, young people up to 20 kHz). What makes MP3 really lossy are the masking effects that MP3's psychoacoustic model describes, i.e. frequencies which are masked are encoded with lower precision by audio coders, thus information are lost.

Audiophiles don't use phones to listen to music anyway, they buy and use proper hardware. All these pseudo DJs with their iPads who feel cool because they can get two channels from a single audio plug with an adapter because they combine two mono channels for the stereo output which is split by an adapter so they can use their overpriced fully automated apps...

I fully agree about the separation of concerns, as stated above.

By the way: MP3 is a free standard now! As Fraunhofer IIS announced recently, the patents are EOL now: https://www.iis.fraunhofer.de/en/ff/amm/prod/audiocodec/audiocodecs/mp3.html
So that's definitely not going to cause problems ever again.

My background by the way: my current job is about audio coding and communication, so I have quite a background in that, too. Also, I'm a hobby DJ and musician, too, and occasionally host some live events.

@utack
Copy link

utack commented May 15, 2017

@TheAssassin youtube's highest bitrate for stereo audio is somewhere in the 128kbit/s range, the lowest bitrate is around 50kbit/s
So if people are really desperate for some few megabytes, adding the option to download the smallest opus file is the option to go for, not downloading the 128kbit/s opus first and then converting to to 50kbit/s mp3

@anilgulecha
Copy link

I have a usecase for transfering long talks to a device which only supports mp3 as the format. So if it's possible to include an mp3 encode in the app, this would be a much used feature.

@theScrabi
Copy link
Member

Answer to this here. Well get there eventually :D

@theScrabi
Copy link
Member

serveimage

brarcher/video-transcoder#42 (comment)

@theScrabi
Copy link
Member

@brarcher notified us that the upcomming version 0.8 of video-decoder will have an intent interface which we call, so now we can finally start and implement this:
brarcher/video-transcoder#42 (comment)

@theScrabi theScrabi added feature request Issue is related to a feature in the app help wanted Help is wanted in fixing this issue labels May 20, 2018
@theScrabi theScrabi changed the title MP3 support when? add mp3 support May 20, 2018
@stale
Copy link

stale bot commented Dec 1, 2018

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@xlotlu
Copy link

xlotlu commented Dec 24, 2018

This issue is still of interest, as old devices are still in use, and sometimes impractical to upgrade.

My use-case is playing the files on the car stereo, which only supports mp3. (and it's really not all that old...)

@opusforlife2
Copy link
Collaborator

@TobiGr @Stypox I think it's been decided overall that it is outside Newpipe's purview to transcode media. Should this and related issues be closed?

@Stypox
Copy link
Member

Stypox commented Mar 19, 2020

I think this issue has the "help wanted" label, that is, if someone finds a small embeddable mp3 converting library it would be ok to use it

@wb9688 wb9688 mentioned this issue Apr 30, 2020
@Stypox Stypox mentioned this issue Sep 21, 2020
This was referenced Jan 18, 2021
@BrajBliss
Copy link

Is this still not available? Because I don't see mp3 download option @mhmdanas

@Stypox
Copy link
Member

Stypox commented Jan 22, 2021

The issue is open, hence no

@ghost
Copy link

ghost commented Dec 30, 2021

youtube-dl can currently convert to MP3 using the --audio-format flag. As for libs which can convert ffmpeg is probably the way to go. Those looking for MP3s check out Spotiflyer.

@renezito
Copy link

renezito commented Feb 2, 2023

Hi! Thanks for this great app and the way you Made it (order and configuration details we can set).
About download audio in mp3, You say that the size will increment a lot.
Take a look to this size comparison between NewPipe and Videoder (a great app to download video and audio in mp3 format from different sites, unfortunately it stopped working). The size is the same :-) So I think u can add the library :D

https://drive.google.com/file/d/17DjYSxikl6sZ2uWAEd5cujY_MaT7CAAR/view?usp=drivesdk

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request Issue is related to a feature in the app help wanted Help is wanted in fixing this issue
Projects
None yet
Development

No branches or pull requests