IPB

Welcome Guest ( Log In | Register )

8 Pages V  < 1 2 3 4 > »   
Reply to this topicStart new topic
libebur128 - (yet another) EBU R 128 implementation
pbelkner
post Jan 16 2011, 18:49
Post #26





Group: Members
Posts: 412
Joined: 13-June 10
Member No.: 81467



QUOTE (Raiden @ Jan 16 2011, 18:47) *
I've thought long about this. There are five filter coefficients for a normalized, second-order IIR filter like the ones in BS.1770-1. Such a filter depends on five design parameters: High-pass gain, band-pass gain, low-pass gain, Q factor, and angular frequency (K = tan(pi * f_c / f_s), f_s is the sampling frequency, f_c the frequency "where it happens").

Sounds very similar to what I've found during my Web search:
http://www.musicdsp.org/files/Audio-EQ-Cookbook.txt

QUOTE (Raiden @ Jan 16 2011, 18:47) *
If one knows how the filter was designed, one can solve the resulting system of equations to get the parameters.

After skipping through the above linked paper I thought exactly about this but had no idea where to begin.

QUOTE (Raiden @ Jan 16 2011, 18:47) *
Yesterday I had some fun with Maxima and LaTeX, and wrote a little paper that explains what I did.

This paper was very helpful. On page 3 there are formulas for b_0, b_1, b_2, a_1, a_2, obtained with bilinear transform.

Many thanks for providing the links.
Go to the top of the page
+Quote Post
benski
post Jan 16 2011, 20:24
Post #27


Winamp Developer


Group: Developer
Posts: 669
Joined: 17-July 05
From: Ashburn, VA
Member No.: 23375



QUOTE (pbelkner @ Jan 16 2011, 10:46) *
On the other hand I'm also interested in Raiden's method for calculating the filter coefficients for various sample rates on the fly. I've searched the whole net several times, ask the question in the forum, unfortunately no answer yet.


It's known as the bilinear transform. It maps analog filter coefficients to digital ones, warping the frequencies to fit properly within a bandlimited system. It's a common technique used for filters that require dynamically calculated filter coefficients (such as an EQ).
Go to the top of the page
+Quote Post
pbelkner
post Jan 16 2011, 20:32
Post #28





Group: Members
Posts: 412
Joined: 13-June 10
Member No.: 81467



QUOTE (benski @ Jan 16 2011, 21:24) *
QUOTE (pbelkner @ Jan 16 2011, 10:46) *
On the other hand I'm also interested in Raiden's method for calculating the filter coefficients for various sample rates on the fly. I've searched the whole net several times, ask the question in the forum, unfortunately no answer yet.


It's known as the bilinear transform. It maps analog filter coefficients to digital ones, warping the frequencies to fit properly within a bandlimited system. It's a common technique used for filters that require dynamically calculated filter coefficients (such as an EQ).

Thanks a lot. I don't have any experience with DSP so far, it's a long way to go ...
Go to the top of the page
+Quote Post
Notat
post Jan 16 2011, 21:40
Post #29





Group: Members
Posts: 581
Joined: 17-August 09
Member No.: 72373



QUOTE (C.R.Helmrich @ Jan 16 2011, 15:28) *
If you want to have my opinion: I'm pretty sure the true peak values can be estimated quite accurately without resampling, so please don't consider adding resampling in the future.

R128 requires oversampling to compute dBTP. If you don't need dBTP, you don't need to oversample. If you're using this library to do Replay Gain tagging, you want to know sample peak because that is what Replay Gain specifies you should tag. The value of dBTP metering depends on the application. On one hand, modern DACs don't have a problem decoding signals greater than 0 dBTP. On the other hand, staying below 0 dBTP is good practice; it keeps you from going over full scale through sample rate conversion.
Go to the top of the page
+Quote Post
Notat
post Jan 16 2011, 21:46
Post #30





Group: Members
Posts: 581
Joined: 17-August 09
Member No.: 72373



QUOTE (Raiden @ Jan 16 2011, 09:47) *
Yesterday I had some fun with Maxima and LaTeX, and wrote a little paper that explains what I did.

Your contributions are appreciated. If you don't have an objection, I may eventually want to use this as a basis generalize the RG filter specification. Right now it only calls out coefficients for 48 and 44.1 kHz implementations.
Go to the top of the page
+Quote Post
lvqcl
post Jan 16 2011, 21:58
Post #31





Group: Developer
Posts: 3219
Joined: 2-December 07
Member No.: 49183



QUOTE
now it only calls out coefficients for 48 and 44.1 kHz implementations


wvgain.c from WavPack sources contains coefficients for frequencies from 8 kHz to 192 kHz
Go to the top of the page
+Quote Post
Raiden
post Jan 17 2011, 00:18
Post #32





Group: Developer
Posts: 224
Joined: 14-September 04
Member No.: 17002



QUOTE (Notat @ Jan 16 2011, 21:46) *
QUOTE (Raiden @ Jan 16 2011, 09:47) *
Yesterday I had some fun with Maxima and LaTeX, and wrote a little paper that explains what I did.

Your contributions are appreciated. If you don't have an objection, I may eventually want to use this as a basis generalize the RG filter specification. Right now it only calls out coefficients for 48 and 44.1 kHz implementations.

Please go ahead! If you need the Maxima/tex source code, it's here.
Go to the top of the page
+Quote Post
Raiden
post Jan 17 2011, 00:25
Post #33





Group: Developer
Posts: 224
Joined: 14-September 04
Member No.: 17002



QUOTE (C.R.Helmrich @ Jan 16 2011, 14:28) *
If you want to have my opinion: I'm pretty sure the true peak values can be estimated quite accurately without resampling, so please don't consider adding resampling in the future.

I have now implemented sample peak measurement... Maybe I'll add true peak measurement but make it optional. Scanning speed will remain the primary goal.
QUOTE (C.R.Helmrich @ Jan 16 2011, 14:28) *
And if I read your code correctly, you store every block energy in your linked list, even the ones which are quieter than -70 LUFS (which you don't need later). I assume that's a design limitation (buffering, album gain handling, and stuff)?

Thanks for pointing that out! Now those blocks are not saved anymore.
Go to the top of the page
+Quote Post
Notat
post Jan 17 2011, 00:35
Post #34





Group: Members
Posts: 581
Joined: 17-August 09
Member No.: 72373



QUOTE (lvqcl @ Jan 16 2011, 13:58) *
QUOTE
now it only calls out coefficients for 48 and 44.1 kHz implementations


wvgain.c from WavPack sources contains coefficients for frequencies from 8 kHz to 192 kHz

Yes, for discrete frequencies, not a compact, closed-form representation of the coefficients as a function of sampling frequency that Raiden has presented here.

This post has been edited by Notat: Jan 17 2011, 00:38
Go to the top of the page
+Quote Post
Raiden
post Jan 17 2011, 00:42
Post #35





Group: Developer
Posts: 224
Joined: 14-September 04
Member No.: 17002



0.1.4 has been uploaded, with the following new features:
- r128-sndfile now supports MP1/2/3 via libmpg123. Now r128-ffmpeg should only be needed for formats that libsndfile and libmpg123 can't handle, like AC3 etc. If you use the precompiled Win32 binaries, you'll need the libmpg123 dll from here.
- r128-sndfile now supports measurement of peak values for the ReplayGain tags.
- the library now has a function ebur128_loudness_range, that implements the loudness range measurement algorithm described in EBU - TECH 3342. You can test it with r128-sndfile and the command line option "-r". The test cases already work quite well:
CODE
seq-3342-1-16bit.wav - LRA: 10.001105
seq-3342-2-16bit.wav - LRA: 4.999373
seq-3342-3-16bit.wav - LRA: 19.995064
seq-3342-4-16bit.wav - LRA: 14.999274
seq-3341-7_seq-3342-5-24bit.wav - LRA: 4.974759
seq-3341-8_seq-3342-6-24bit.wav - LRA: 14.993651


Source (tar.gz)
Source (zip)
Win32 build (zip)
Go to the top of the page
+Quote Post
pbelkner
post Jan 17 2011, 18:22
Post #36





Group: Members
Posts: 412
Joined: 13-June 10
Member No.: 81467



QUOTE (Raiden @ Jan 16 2011, 18:47) *
Yesterday I had some fun with Maxima and LaTeX, and wrote a little paper that explains what I did.

This paper was very helpful. On page 3 there are formulas for b_0, b_1, b_2, a_1, a_2, obtained with bilinear transform.

Many thanks again for providing the links. It's just like pointing me to a goldmine.

As far as I understand, you are calculating
K, Q, Vh, Vb, Vl, from K also Fc
from the given a0...b2.

Am I right in assuming that Q, Vh, Vb, Vl and Fc remain constant for all sample rates and only K has to be adapted accordingly?

This post has been edited by pbelkner: Jan 17 2011, 18:23
Go to the top of the page
+Quote Post
benski
post Jan 17 2011, 19:11
Post #37


Winamp Developer


Group: Developer
Posts: 669
Joined: 17-July 05
From: Ashburn, VA
Member No.: 23375



Correct.

V are gain values and have no relation to sampling frequency
Q is a "magic number" that effects the shape of the filter.

Fc stays constant - it's the nominal cutoff frequency. ω is tan(fc/fs *π) [it has been typo'd as Ω in the paper, ω/Ω are lowercase/uppercase pairs]. That is, it's the cutoff frequency as a percentage of the sampling rate, and "pre-warped" with tan() to match the frequency warping done by the bilinear transform. k is often used for ω in source code.
Go to the top of the page
+Quote Post
verdemar
post Jan 17 2011, 21:36
Post #38





Group: Members
Posts: 42
Joined: 10-February 06
Member No.: 27674



Thanks, works very well for me.

Just thought I'd mention that the python tagging script did not work out of the box on my system (python 2.6.5), I get the following error message:
CODE
Traceback (most recent call last):
  File "../src/rgtag.py", line 4, in <module>
    tg = '{:.2f}'.format(float(sys.argv[2])) + " dB"
ValueError: zero length field name in format


Substituting with an alternative string formatting, it works like a charm:
CODE
tg = "%.2f dB" % float(sys.argv[2])
tp = "%.8f"    % float(sys.argv[3])
ag = "%.2f dB" % float(sys.argv[4])
ap = "%.8f"    % float(sys.argv[5])
Go to the top of the page
+Quote Post
Raiden
post Jan 18 2011, 23:53
Post #39





Group: Developer
Posts: 224
Joined: 14-September 04
Member No.: 17002



QUOTE (verdemar @ Jan 17 2011, 21:36) *
Substituting with an alternative string formatting, it works like a charm:

Thank you for the fix! This is (literally) my first python script. smile.gif
Go to the top of the page
+Quote Post
Raiden
post Jan 19 2011, 00:21
Post #40





Group: Developer
Posts: 224
Joined: 14-September 04
Member No.: 17002



Version 0.1.5 has arrived!
- I've seperated the scanners. They all support the same options and differ just in the input formats. There are:
-- r128-sndfile (for Vorbis, FLAC, WAV, and many others)
-- r128-mpg123 (for MP1, MP2, MP3)
-- r128-musepack
-- r128-ffmpeg (everything else)
- Added needed DLLs (FFmpeg is compiled as LGPL version)
- Added Musepack support to the tagging script
- Many improvements in the library (thanks to C.R.Helmrich!)
- Fixed loudness range calculation. In 0.1.4, when a new segment was started, calculation stopped. This is now fixed!
- Minor bug fixes.
- A Win64 build! Please let me know if it works. It's 20-30% faster than the Win32 build. This is probably because SSE optimizations are not enabled in the Win32 build. I will try to do this soon.

Source (tar.gz)
Source (zip)
Win32 build
Win64 build
Go to the top of the page
+Quote Post
pbelkner
post Jan 19 2011, 16:40
Post #41





Group: Members
Posts: 412
Joined: 13-June 10
Member No.: 81467



QUOTE (benski @ Jan 17 2011, 20:11) *
Correct.

V are gain values and have no relation to sampling frequency
Q is a "magic number" that effects the shape of the filter.

Fc stays constant - it's the nominal cutoff frequency. ω is tan(fc/fs *π) [it has been typo'd as Ω in the paper, ω/Ω are lowercase/uppercase pairs]. That is, it's the cutoff frequency as a percentage of the sampling rate, and "pre-warped" with tan() to match the frequency warping done by the bilinear transform. k is often used for ω in source code.

I've finally managed (thanks to the pointers provided by Raiden) to find a closed solution to the re-quantization problem for digital biquad filters as it appears in the context of (but not restricted to) BS.1770.

Assume youv'e given the coefficients a1, a2, b0, b1, b2, b3 of a digital biquad filter for a particular sample frequency Fs (cf. e.g. http://www.musicdsp.org/files/Audio-EQ-Cookbook.txt).

The re-quantization problem consists in calculating the coefficents a1', a2', b0', b1', b2', and b3' of a digital biquad filter with the same characteristics as the given one, but for another sample frequency Fs'.

The key to the solution are the pointers provided by Raiden:
  1. Brian Neunaber: Parameter Quantization in Direct-Form Recursive Audio Filters
  2. Raiden: ITU-R BS.1770-1 filter specifications, January 15, 2011
According to [1] the coeffients a1, a2, b0, b1, b2 of the given digital biquad filter can be mapped to the parameters Fc, Q, Vl, Vb, and Vh of the corresponding analog filter by the following equations (using the notation from [2]):

CODE
(1)    (1 + K / Q + K^2) * a1  =  2 * (K^2 - 1)
(2)    (1 + K / Q + K^2) * a2  =  1 - K / Q + K^2
(3)    (1 + K / Q + K^2) * b0  =  Vh + Vb * K / Q + Vl * K^2
(4)    (1 + K / Q + K^2) * b1  =  2 * (Vl * K^2 - Vh)
(5)    (1 + K / Q + K^2) * b2  =  Vh - Vb * K / Q + Vl * K^2

with

CODE
(6) K = tan(pi * Fc / Fs).

In order to solve the above stated re-quantization problem we do the following:
  1. Solve the eqs (1) - (5) for Fc, Q, Vl, Vb, and Vh.
  2. Use the equations

    CODE
    (1')    (1 + K' / Q + K'^2) * a1'  =  2 * (K'^2 - 1)
    (2')    (1 + K' / Q + K'^2) * a2'  =  1 - K' / Q + K'^2
    (3')    (1 + K' / Q + K'^2) * b0'  =  Vh' + Vb' * K' / Q + Vl * K'^2
    (4')    (1 + K' / Q + K'^2) * b1'  =  2 * (Vl * K'^2 - Vh)
    (5')    (1 + K' / Q + K'^2) * b2'  =  Vh - Vb * K' / Q + Vl * K^2

    with

    CODE
    (6') K' = tan(pi * Fc / Fs')

    in order to calculate the coefficents a1', a2', b0', b1', and b2' for a digital biquad filter with the same characteristcs Fc, Q, Vl, Vb, and Vh as the given one but for a different sample frequency Fs'.
We start by solving eqs. (1) and (2) for K^2 and K/Q, respectively. By substituting

CODE
x11  =  a1 - 2
x12  =  a1
x1  =  -a1 - 2

x21  =  a2 - 1
x22  =  a2 + 1
x2  =  -a2 + 1

DX = x22 * x11 - x12 * x21

and using well known methods we arrive at

CODE
(6)  K^2  =  (x22 * x1 - x12 * x2) / DX
(7)  K/Q  =  (x11 * x2 - x21 * x1) / DX

Next we solve eqs. (3), (4), and (5) for Vh, Vb, and Vl. Introducing

CODE
(8) a0  =  1 + K / Q + K^2

and reordering eqs. (3), (4), and (5) they read

CODE
(3a)       Vh + K/Q * Vb +       K^2 * Vl  =  b0 * a0
(4a)  -2 * Vh            + (2 * K^2) * Vl  =  b1 * a0
(5a)       Vh - K/Q * Vb +       K^2 * Vl  =  b2 * a0

Now it's not hard any longer to find the solutions:

CODE
            a0 * (b0 - b2)
(9)  Vb  =  --------------
               2 * K/Q

            a0 * (b0 + b1 + b2)
(10) Vl  =  -------------------
                  4 * K^2

            a0 * (b0 - b1 + b2)
(11) Vh  =  -------------------
                    4

Finally we observe from eqs. (6) and (6') the following:

CODE
(6)     K   =  tan(pi * Fc / Fs)
(6)'    K'  =  tan(pi * Fc / Fs')
(12)   K'  =  tan(atan(K) * Fs / Fs')

Eqs. (6) and (7) along with (9), (10), (11), and (12) provide everything we need for re-quantizing any given digital biquad filter. We demonstrate this by the following C code (please note that this code re-quantizes digital biqad filters on the fly, no pre-processing by an external algebra system ist needed).

CODE
typedef struct biquad {
  double fs;
  double a1, a2;
  double b0, b1, b2;
} biquad_t;

typedef struct biquad_ps {
  double k;
  double q;
  double vb;
  double vl;
  double vh;
} biquad_ps_t;

void biquad_get_ps(biquad_t *biquad, biquad_ps_t *ps)
{
  double x11 = biquad->a1 - 2;
  double x12 = biquad->a1;
  double x1 = -biquad->a1 - 2;

  double x21 = biquad->a2 - 1;
  double x22 = biquad->a2 + 1;
  double x2 = -biquad->a2 + 1;

  double dx = x22*x11 - x12*x21;
  double k_sq = (x22*x1 - x12*x2)/dx;
  double k_by_q = (x11*x2 - x21*x1)/dx;
  double a0 = 1.0 + k_by_q + k_sq;

  ps->k = sqrt(k_sq);
  ps->q = ps->k/k_by_q;
  ps->vb = 0.5*a0*(biquad->b0 - biquad->b2)/k_by_q;
  ps->vl = 0.25*a0*(biquad->b0 + biquad->b1 + biquad->b2)/k_sq;
  ps->vh = 0.25*a0*(biquad->b0 - biquad->b1 + biquad->b2);
}

biquad_t *biquad_requantize(biquad_t *in, biquad_t *out)
{
  if (in->fs==out->fs)
    return in;
  else {
    biquad_ps_t ps;
    double k, k_sq, k_by_q, a0;

    biquad_get_ps(in, &ps);
    k=tan((in->fs/out->fs)*atan(ps.k));
    k_sq = k*k;
    k_by_q = k/ps.q;
    a0 = 1.0 + k_by_q + k_sq;

    out->a1 = (2.0*(k_sq - 1.0))/a0;
    out->a2 = (1.0 - k_by_q + k_sq)/a0;
    out->b0 = (ps.vh + ps.vb*k_by_q + ps.vl*k_sq)/a0;
    out->b1 = (2.0 * (ps.vl*k_sq - ps.vh))/a0;
    out->b2 = (ps.vh - ps.vb*k_by_q + ps.vl*k_sq)/a0;

    return out;
  }
}

The following code demonstrates how to re-quantize the 48 kHz BS.1770 pre-filter to it's 44.1 kHz equivalent using the above functions.

CODE
int main(int argc, char **argv)
{
  int i;

  biquad_t pre48000={
    .fs=48000,
    .a1=-1.69065929318241,
    .a2=0.73248077421585,
    .b0=1.53512485958697,
    .b1=-2.69169618940638,
    .b2=1.19839281085285
  };

  biquad_t pre44100={ .fs=44100 };

  biquad_requantize(&pre48000, &pre44100);
  printf("a1: %f, %f\n", pre48000.a1, pre44100.a1);
  printf("a2: %f, %f\n", pre48000.a2, pre44100.a2);
  printf("b1: %f, %f\n", pre48000.b0, pre44100.b0);
  printf("b2: %f, %f\n", pre48000.b1, pre44100.b1);
  printf("b3: %f, %f\n", pre48000.b2, pre44100.b2);
}


This post has been edited by pbelkner: Jan 19 2011, 16:41
Go to the top of the page
+Quote Post
Raiden
post Jan 23 2011, 16:49
Post #42





Group: Developer
Posts: 224
Joined: 14-September 04
Member No.: 17002



QUOTE (pbelkner @ Jan 19 2011, 16:40) *
The following code demonstrates how to re-quantize the 48 kHz BS.1770 pre-filter to it's 44.1 kHz equivalent using the above functions.

I get exactly the same coefficients. Nice work!
Go to the top of the page
+Quote Post
Raiden
post Jan 23 2011, 17:00
Post #43





Group: Developer
Posts: 224
Joined: 14-September 04
Member No.: 17002



I've uploaded 0.1.6:
- The main new feature is a scanning/tagging script written in Python. It takes one or more directory(ies) as input and scans them for music files. If there are many directories, it will scan them in parallel to use all available cores:
CODE
usage: r128-tag [-r] <directory(ies)> ...
       r128-tag <file(s)> ...

    -h: show this help
    -r: scan directory(ies) recursively

  r128-tag scans music files and tags them with ReplayGain compatible tags.
  If more than one directory is given, all available cores will be used.

- optimized the LRA calculations
- some minor library improvements
- Linux builds!

Source (tar.gz)
Source (zip)
Win32 build (zip)
Win64 build (zip)
Linux32 build (tar.gz)
Linux64 build (tar.gz)
Go to the top of the page
+Quote Post
hödyr
post Jan 23 2011, 18:17
Post #44





Group: Members
Posts: 134
Joined: 26-January 02
Member No.: 1171



Any idea why r128-mpg123 does not work for me on Windows 7 x64?
CODE
C:\Users\frost\Downloads\libebur128-0.1.6-win64>python ./r128-tag.py -r "C:\User
s\frost\Downloads\Motörhead\2008 - Motörizer"
Note: Illegal Audio-MPEG-Header 0x41504554 at offset 5074432.
Note: Trying to resync...
Note: Skipped 1024 bytes in input.
Internal MPG123 error!
Note: Illegal Audio-MPEG-Header 0x41504554 at offset 5106947.
Note: Trying to resync...
Note: Skipped 1024 bytes in input.
Internal MPG123 error!
Note: Illegal Audio-MPEG-Header 0x41504554 at offset 5802950.
Note: Trying to resync...
Note: Skipped 1024 bytes in input.
Internal MPG123 error!

These are normal MP3 files encoded with Lame 3.93. If i strip all tags from the file it doesn't complain anymore. Files are tagged with ID3 and APEv2.


--------------------
Blubb
Go to the top of the page
+Quote Post
C.R.Helmrich
post Jan 23 2011, 20:00
Post #45





Group: Developer
Posts: 682
Joined: 6-December 08
From: Erlangen Germany
Member No.: 64012



Thanks for the new version. When I check the same file twice by calling r128-sndfile {-t} file.wav file.wav, I sometimes get slightly different results (by 0.01 LU or so). Could this indicate an initialization bug? The same happens on version 0.1.5.

Btw, did you manage to get the Win32 build SSE optimized?

Chris

This post has been edited by C.R.Helmrich: Jan 23 2011, 20:06


--------------------
If I don't reply to your reply, it means I agree with you.
Go to the top of the page
+Quote Post
Raiden
post Jan 23 2011, 20:28
Post #46





Group: Developer
Posts: 224
Joined: 14-September 04
Member No.: 17002



QUOTE (C.R.Helmrich @ Jan 23 2011, 20:00) *
Thanks for the new version. When I check the same file twice by calling r128-sndfile {-t} file.wav file.wav, I sometimes get slightly different results (by 0.01 LU or so). Could this indicate an initialization bug? The same happens on version 0.1.5.

This is intentional (for now). When starting a new segment, the last unfinished block of the last segment does not get dropped, but becomes the first block of the new segment. Only the last unfinished block of the whole programme gets dropped. I wonder how other implementations and ReplayGain scanners handle this edge-case.

QUOTE (C.R.Helmrich @ Jan 23 2011, 20:00) *
Btw, did you manage to get the Win32 build SSE optimized?

Not yet... But it should just be "-msse2 -mfpmath=sse" so I will do it in the next version.
Go to the top of the page
+Quote Post
Raiden
post Jan 23 2011, 20:42
Post #47





Group: Developer
Posts: 224
Joined: 14-September 04
Member No.: 17002



QUOTE (hödyr @ Jan 23 2011, 18:17) *
Any idea why r128-mpg123 does not work for me on Windows 7 x64?
These are normal MP3 files encoded with Lame 3.93. If i strip all tags from the file it doesn't complain anymore. Files are tagged with ID3 and APEv2.

Thanks for the report! I could reproduce with APEv2 tagged MP3's. It looks like MPG123 sees APE tags as errors in the stream (which they are in some way, I guess wink.gif). I will try to handle this more gracefully.
Go to the top of the page
+Quote Post
Raiden
post Jan 23 2011, 23:05
Post #48





Group: Developer
Posts: 224
Joined: 14-September 04
Member No.: 17002



Version 0.1.7 is just a bug fix:
- Handle MP3's with APEv2 tags more gracefully
- 32 bit builds are now compiled with SSE2 support (~10-20% performace improvement).

Source (tar.gz)
Source (zip)
Win32 build (zip)
Win64 build (zip)
Linux32 build (tar.gz)
Linux64 build (tar.gz)
Go to the top of the page
+Quote Post
hödyr
post Jan 24 2011, 11:55
Post #49





Group: Members
Posts: 134
Joined: 26-January 02
Member No.: 1171



Thanks. Could you fix the build script to run on FreeBSD? It has troubles finding libraries. I got r128-mpg123 to compile by installing mpg123 and making a symlink:
CODE
ln -s /usr/local/lib/libmpg123.so /lib/libmpg123.so

Same for r128-sndfile:
CODE
ln -s /usr/local/lib/libsndfile.so /lib/libsndfile.so

And for r128-ffmpeg you have to create 2 symlinks:
CODE
ln -s /usr/local/lib/libavcodec.so /lib/libavcodec.so
ln -s /usr/local/lib/libavformat.so /lib/libavformat.so


After this the software is running fine on FreeBSD, unfortunately, I couldn't use the python script:
CODE
Traceback (most recent call last):
  File "./r128-tag.py", line 112, in <module>
    pool = multiprocessing.Pool(processes=number_threads)
  File "/usr/local/lib/python2.6/multiprocessing/__init__.py", line 227, in Pool
    return Pool(processes, initializer, initargs)
  File "/usr/local/lib/python2.6/multiprocessing/pool.py", line 84, in __init__
    self._setup_queues()
  File "/usr/local/lib/python2.6/multiprocessing/pool.py", line 130, in _setup_queues
    from .queues import SimpleQueue
  File "/usr/local/lib/python2.6/multiprocessing/queues.py", line 22, in <module>
    from multiprocessing.synchronize import Lock, BoundedSemaphore, Semaphore, Condition
  File "/usr/local/lib/python2.6/multiprocessing/synchronize.py", line 33, in <module>
    " function, see issue 3770.")
ImportError: This platform lacks a functioning sem_open implementation, therefore, the required synchronization primitives needed will not function, see issue 3770.


Solution is to compile lang/python27 or whatever version you prefer and enable SEM and PTH options. Then forget to install mutagen and uncomment try-expect block to learn about it, install mutagen and voilá: Runs on FreeBSD biggrin.gif.

This post has been edited by hödyr: Jan 24 2011, 11:55


--------------------
Blubb
Go to the top of the page
+Quote Post
Raiden
post Jan 24 2011, 12:45
Post #50





Group: Developer
Posts: 224
Joined: 14-September 04
Member No.: 17002



QUOTE (hödyr @ Jan 24 2011, 11:55) *
Thanks. Could you fix the build script to run on FreeBSD? It has troubles finding libraries. I got r128-mpg123 to compile by installing mpg123 and making a symlink:

Yay! Another BSD user smile.gif Development so far is done on Linux, but I will try to build on FreeBSD later today.
QUOTE (hödyr @ Jan 24 2011, 11:55) *
After this the software is running fine on FreeBSD, unfortunately, I couldn't use the python script:
Solution is to compile lang/python27 or whatever version you prefer and enable SEM and PTH options. Then forget to install mutagen and uncomment try-expect block to learn about it, install mutagen and voilá: Runs on FreeBSD biggrin.gif.

Awesome. I've already made the multiprocessing module optional and improved the tagging error messages.
Go to the top of the page
+Quote Post

8 Pages V  < 1 2 3 4 > » 
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 24th April 2014 - 06:21