23 May
2019
23 May
'19
12:59 p.m.
Hey everyone!
I need advice on resampling.
To give you context, I am working at SoundCloud, and one of the current
projects is to refactor the transcoding pipeline. And proper resampling
tools is a question that keeps coming up.
One of the pipelines takes the uploaded file and transcodes it into an mp3.
The general idea is to convert the original file to wav, resample it to
44100, and then finally convert it to mp3 using LAME.
There are several questions here.
1. Which tool to use for transcoding. Should it be SoX, or FFmpeg, or
something else? A lot of the info out there seems to favor SoX, but a lot
of that info is pretty old.
2. Does it make sense to resample to 44100 or to 48000? If it were opus,
the answer if simple: 48000, because that's what the opus spec actually
recommends. There is no such recommendation for mp3 files. Also, upsampling
is not an innocent procedure and the converter has to be of high quality as
well.
p.s.: the described pipeline is not the only one, the original file is
transcoded into multiple formats, including formats with 48000 sample rate,
but the one I am asking about focuses specifically on producing an mp3.
Louigi Verona
https://louigiverona.com/
23 May
23 May
1:59 p.m.
On 2019-05-23 10:58:54 (+0200), Louigi Verona wrote:
There are several questions here.
1. Which tool to use for transcoding. Should it be SoX, or FFmpeg, or
something else? A lot of the info out there seems to favor SoX, but a lot
of that info is pretty old.
I'm currently maintaining sox for Arch Linux and I
would suggest to use
ffmpeg instead. It's by far the more active and maintained upstream.
Sox is pretty much dead by now (hasn't seen a release since 2015). The
latest (two year old) fixes for pretty extreme CVEs [1] haven't even
found their way into a latest stable release [2] anymore and getting no
answer on such a request doesn't exactly nurture my belief in the
project. However, the patches have been applied on master.
Looking at the current list of CVEs, I see, that it has gained yet
another four CVEs this year alone, that I have to add to the list of
patches!
This is literally nothing you would want to put into an automated
pipeline (but it's also your developer's/ your call ;-) ).
2. Does it make sense to resample to 44100 or to
48000? If it were opus,
the answer if simple: 48000, because that's what the opus spec actually
recommends. There is no such recommendation for mp3 files. Also, upsampling
is not an innocent procedure and the converter has to be of high quality as
well.
Not an expert, but I wouldn't recommend upsampling.
Best,
David
[1] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=sox
[2] https://sourceforge.net/p/sox/mailman/message/36432794/
--
https://sleepmap.de
4:40 p.m.
On Thu, May 23, 2019 at 2:59 AM Louigi Verona <louigi.verona(a)gmail.com>
wrote:
Hey everyone!
I need advice on resampling.
To give you context, I am working at SoundCloud, and one of the current
projects is to refactor the transcoding pipeline. And proper resampling
tools is a question that keeps coming up.
One of the pipelines takes the uploaded file and transcodes it into an
mp3. The general idea is to convert the original file to wav, resample it
to 44100, and then finally convert it to mp3 using LAME.
There are several questions here.
1. Which tool to use for transcoding. Should it be SoX, or FFmpeg, or
something else? A lot of the info out there seems to favor SoX, but a lot
of that info is pretty old.
In terms of quality for resampling, this is the canonical information
source: http://src.infinitewave.ca/
5:58 p.m.
"In terms of quality for resampling, this is the canonical information
source: http://src.infinitewave.ca/"
Yep, was looking at that. But would appreciate any additional insight,
since I am not entirely sure how to read that. For instance, if I compare
SoX to FFmpeg, yes, SoX looks way better in this particular case. Question
is - are these meaningful differences?
Also, the test goes from 96kHz back to 44.1kHz, and people very rarely
upload 96kHz.
So, I would mostly be interested in 48->44.1 and 44.1->44.1. Specifically,
does anything change in the latter case?
6:39 p.m.
The good news is that ffmpeg appears to include the soxr algorithm anyway.
On Thu, May 23, 2019 at 7:58 AM Louigi Verona <louigi.verona(a)gmail.com>
wrote:
"In terms of quality for resampling, this is the
canonical information
source: http://src.infinitewave.ca/"
Yep, was looking at that. But would appreciate any additional insight,
since I am not entirely sure how to read that. For instance, if I compare
SoX to FFmpeg, yes, SoX looks way better in this particular case. Question
is - are these meaningful differences?
Also, the test goes from 96kHz back to 44.1kHz, and people very rarely
upload 96kHz.
So, I would mostly be interested in 48->44.1 and 44.1->44.1. Specifically,
does anything change in the latter case?
6:41 p.m.
Is this so? Or should it be specifically compiled with the SoX library?
Louigi Verona
https://louigiverona.com/
On Thu, May 23, 2019 at 4:39 PM Paul Davis <paul(a)linuxaudiosystems.com>
wrote:
The good news is that ffmpeg appears to include the
soxr algorithm anyway.
On Thu, May 23, 2019 at 7:58 AM Louigi Verona <louigi.verona(a)gmail.com>
wrote:
"In terms of quality for resampling, this is
the canonical information
source: http://src.infinitewave.ca/"
Yep, was looking at that. But would appreciate any additional insight,
since I am not entirely sure how to read that. For instance, if I compare
SoX to FFmpeg, yes, SoX looks way better in this particular case. Question
is - are these meaningful differences?
Also, the test goes from 96kHz back to 44.1kHz, and people very rarely
upload 96kHz.
So, I would mostly be interested in 48->44.1 and 44.1->44.1.
Specifically, does anything change in the latter case?
6:48 p.m.
On Thu, May 23, 2019 at 8:41 AM Louigi Verona <louigi.verona(a)gmail.com>
wrote:
Is this so? Or should it be specifically compiled with
the SoX library?
Louigi Verona
https://louigiverona.com/
On Thu, May 23, 2019 at 4:39 PM Paul Davis <paul(a)linuxaudiosystems.com>
wrote:
https://trac.ffmpeg.org/wiki/FFmpeg%20and%20the%20SoX%20Resampler
The good news is that ffmpeg appears to include
the soxr algorithm
anyway.
7:01 p.m.
Yep, I've seen this link. But this basically means it has to be compiled
with SoX, and then this algorithm has to be specifically invoked, right.
But by default it uses its own, I guess. So it still leaves us with a
choice - which algo to use?
David makes a good point from a maintenance POV, I wonder if there is an
argument to be made from a DSP point of view, you know.
7:22 p.m.
On 2019-05-23 15:00, Louigi Verona wrote:
But this basically means it has to be compiled with
SoX
Sort of. It needs to be built with soxr (The SoX Resampler library)
https://sourceforge.net/projects/soxr/files/
Cheers,
--
/bengan
7:30 p.m.
On Thu, 23 May 2019, Louigi Verona wrote:
One of the pipelines takes the uploaded file and
transcodes it into an mp3. The
general idea is to convert the original file to wav, resample it to 44100, and
then finally convert it to mp3 using LAME.
There are several questions here.
1. Which tool to use for transcoding. Should it be SoX, or FFmpeg, or something
else? A lot of the info out there seems to favor SoX, but a lot of that info is
pretty old.
2. Does it make sense to resample to 44100 or to 48000? If it were opus, the
answer if simple: 48000, because that's what the opus spec actually recommends.
There is no such recommendation for mp3 files. Also, upsampling is not an
innocent procedure and the converter has to be of high quality as well.
For file in to file out why would anyone resample at all? Just keep the
original sample rate for each file and be happy. For file size, 44k1 is
smaller, but not that much.
48k for opus is not just recomended, it is the speed opus works at
internally. The question is if you want to trust opus internal SRC to 48k
or you want to do your own. For opus using 48k in and out, means no SRC.
For 44k1 in and out, it means SRC to 48k going in and then src to 44k1
going out. But I guess the SRC for playing is not something you would have
control of anyway.
From a selling view point, you want the best experience
for the
greatest number of your users. This probably means testing for cpu load
and best quality on a low end windows machine... I can't help there as I
can't find any windows machines in the house. What rate do the commercial
music distribution people use? (those that charge per song)
--
Len Ovens
www.ovenwerks.net
1800
days inactive
1800
days old
linux-audio-dev@lists.linuxaudio.org
10 comments
6 participants
participants (6)
-
Bengt Gördén -
David Runge -
Len Ovens -
Louigi Verona -
Paul Davis -
Thorsten Wilms