headers
Dan Muresan | 3 Nov 2010 00:03
Picon
Gravatar

Re: lossless conversion broken?

Hi,

> libecasound/eca-sample-conversion.h:
> http://ecasound.git.sourceforge.net/git/gitweb.cgi?p=ecasound/ecasound;a=blob;f=libecasound/eca-sample-conversion.h;h=f11aced93bd9ff2616c5500205d661cc8c554201;hb=HEAD#l96

I looked at the code. I'm surprised at a different asymmetry -- the
one between eca_sample_convert_float_to_s32 vs.
eca_sample_convert_s32_to_float:

int32_t eca_sample_convert_float_to_s32(float inval) {
  if (inval < 0.0f)
    return((int32_t)((float)(inval * (INT32_MAX))));

  return((int32_t)((float)(inval * INT32_MAX) - 0.5f));
}

float eca_sample_convert_s32_to_float(int32_t inval) {
   return(((float)inval) / INT32_MAX);
}

The conversion functions should be (at least mathematically) inverse
functions, i.e. f (g (x)) = x. If you don't distinguish between
positive and negative int's, why do you do so for +/- floats?

> This is unit-tested in libecasound/eca-sample-conversion_test.h:
> http://ecasound.git.sourceforge.net/git/gitweb.cgi?p=ecasound/ecasound;a=blob;f=libecasound/eca-sample-conversion_test.h;h=fa0c52247290c4886dc98889afde9eaac0f8e70d;hb=HEAD

Yes, but that unit test only looks at 0.0f, ((float) INT_MAX) and
((float) INT_MIN). Zero is not distorted, but 1,2,3 etc are:
(Continue reading)

Permalink | Reply | 7 comments |
headers
Sergei Steshenko | 3 Nov 2010 07:40
Picon
Favicon

Re: lossless conversion broken?


--- On Tue, 11/2/10, Dan Muresan <danmbox <at> gmail.com> wrote:

> From: Dan Muresan <danmbox <at> gmail.com>
> Subject: Re: [ecasound] lossless conversion broken?
> To: "Kai Vehmanen" <kvehmanen <at> eca.cx>
> Cc: ecasound-list <at> lists.sourceforge.net
> Date: Tuesday, November 2, 2010, 4:03 PM
> Hi,
> 
> > libecasound/eca-sample-conversion.h:
> > http://ecasound.git.sourceforge.net/git/gitweb.cgi?p=ecasound/ecasound;a=blob;f=libecasound/eca-sample-conversion.h;h=f11aced93bd9ff2616c5500205d661cc8c554201;hb=HEAD#l96
> 
> I looked at the code. I'm surprised at a different
> asymmetry -- the
> one between eca_sample_convert_float_to_s32 vs.
> eca_sample_convert_s32_to_float:
> 
> int32_t eca_sample_convert_float_to_s32(float inval) {
>   if (inval < 0.0f)
>     return((int32_t)((float)(inval *
> (INT32_MAX))));
> 
>   return((int32_t)((float)(inval * INT32_MAX) -
> 0.5f));
> }
> 
> float eca_sample_convert_s32_to_float(int32_t inval) {
>    return(((float)inval) / INT32_MAX);
> }
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kai Vehmanen | 4 Nov 2010 22:02

Re: lossless conversion broken?

Hi,

On Wed, 3 Nov 2010, Dan Muresan wrote:

> I looked at the code. I'm surprised at a different asymmetry -- the
> one between eca_sample_convert_float_to_s32 vs.
> eca_sample_convert_s32_to_float:
>
> int32_t eca_sample_convert_float_to_s32(float inval) {
>  if (inval < 0.0f)
>    return((int32_t)((float)(inval * (INT32_MAX))));
>
>  return((int32_t)((float)(inval * INT32_MAX) - 0.5f));
> }

oh yes, thanks, I've been blind to that completely, that's not right at 
all. Definitely a bug. It sure is depressing to find such stuff... :P

> I agree with the jackit threads -- introducing a nonlinear
> transformation in a chain is not a good thing (from a signals &
> systems POV). Sounds like 0x8000, symmetrical would be best for the
> future. I assume this breaks existing files, which is why you'd have
> to wait for a major release.

Yes, agreed.

------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a 
Billion" shares his insights and actions to help propel your
(Continue reading)

Permalink | Reply | 3 comments |
headers
Stuart Allie | 4 Nov 2010 23:02
Picon
Favicon

Re: lossless conversion broken?


I wouldn't let it worry you Kai.  I once wrote a piece of code that
failed intermittently and for the life of me I couldn't find the bug.  I
went through every line over and over.  Other people read the code and
could see nothing wrong with it.  Seven(!) years later I came across
that old code and out of curiosity started to read through it.  The very
first line had an obvious error in it...  that was the "mystery bug".  

First line.  Obvious error.  The brain is really good at fooling itself
:)

Stuart Allie

> -----Original Message-----
> From: Kai Vehmanen [mailto:kvehmanen <at> eca.cx]
> Sent: Friday, 5 November 2010 8:03 AM
> To: Dan Muresan
> Cc: ecasound-list <at> lists.sourceforge.net
> Subject: Re: [ecasound] lossless conversion broken?
> 
> Hi,
> 
> On Wed, 3 Nov 2010, Dan Muresan wrote:
> 
> > I looked at the code. I'm surprised at a different asymmetry -- the
> > one between eca_sample_convert_float_to_s32 vs.
> > eca_sample_convert_s32_to_float:
> >
> > int32_t eca_sample_convert_float_to_s32(float inval) {
> >  if (inval < 0.0f)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan Muresan | 5 Nov 2010 10:31
Picon
Gravatar

Re: lossless conversion broken?

> oh yes, thanks, I've been blind to that completely, that's not right at all.
> Definitely a bug. It sure is depressing to find such stuff... :P

Well, it had quite a minor impact so that's probabably why it wasn't
noticed. As a previous poster said, I wouldn't let it bother you :)

I'm curious, what are the consistency requirements for a minor vs.
major release? I've just realized that there is no custom Ecasound
file format (i.e. floats never get stored in any files). What would be
affected by changes in the conversion formulas?

Best,
Dan

------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a 
Billion" shares his insights and actions to help propel your 
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
_______________________________________________
Ecasound-list mailing list
Ecasound-list <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecasound-list
Permalink | Reply | 1 comment |
headers
Joel Roth | 6 Nov 2010 15:19
Picon
Favicon

Propagation of signal width with jack inputs

Kai and others,

While looking for something else, I think I found a bug. 

Here is a sample chain setup:

-B auto -r -z:mixmode,sum 

# audio inputs

-a:1 -i:loop,Master_in
-a:3 -f:f32_le,1,44100 -i:jack,,brass_in

# post-input processing

-a:3 -chcopy:1,2

# audio outputs

-a:1 -o:jack_multi,system:playback_1,system:playback_2
-a:3 -o:loop,Master_in

Due to the -chcopy operator on chain 3, I expect the output
to be stereo, but jack_lsp -c and ecasound debugging output
show the output to be mono.

'fs' shows that chain "1" is only one channel wide.

### Audio input/output status (chainsetup '/oldroot/home/jroth/nama/untitled/Setup.ecs') ###
Input (1): "loop,Master_in" - [Internal loop device]
(Continue reading)

Permalink | Reply | 4 comments |
headers
Julien Claassen | 6 Nov 2010 15:27
Picon

Re: Propagation of signal width with jack inputs

Hwello Joel1
   I suppose you might try:
-a:3 -f:f32_le,1,44100 -i:loop,Brass_in
...
-a:3 -f:f32_le,2,44100 -chcopy:1,2
...
   That at least how I learned to use them on the commandline. Inever 
reallythought about Nama's setup in that respect, because all my mono ports 
worked, they were direct jack-connections though.
   Kindly yours
            Julien

--------
Music was my first love and it will be my last (John Miles)

======== FIND MY WEB-PROJECT AT: ========
http://ltsb.sourceforge.net
the Linux TextBased Studio guide
======= AND MY PERSONAL PAGES AT: =======
http://www.juliencoder.de

------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a 
Billion" shares his insights and actions to help propel your 
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
_______________________________________________
Ecasound-list mailing list
Ecasound-list <at> lists.sourceforge.net
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joel Roth | 7 Nov 2010 04:41
Picon
Favicon

Ecasound-JACK buffer size mismatch

Hi Kai and others,

I've been getting this message at random when
connecting a chain setup:

Connecting chainsetup failed: 
"Enabling chainsetup: AUDIOIO-JACK: Cannot connect open connection! 
Buffersize 128 differs from JACK server's buffersize of 1024."

Usually repeating Nama's cs-connect routine is enough to 
clear the error.

Here is the -dd output. Note that the bufferize: line
says 128 in the *warning-free* connects as well.

(eca-session) Connecting chainsetup
jack_client_new: deprecated
(eca-chainsetup) jackd buffersize check returned 1024.
(eca-chainsetup) overriding buffersize.
(eca-chainsetup) Multitrack-mode enabled.
(eca-chainsetup) bmode-selection case-1
(eca-chainsetup) "rt" buffering mode selected.
(eca-chainsetup) Set buffering parameters to:
--cut--     
buffersize: 128
raised_priority: 1
sched_priority: 50
double buffering: 1
double buffer size: 100000
max buffers: 0
(Continue reading)

Permalink | Reply | 1 comment |

Gmane