How do multiple amplitude fades work on ecasound? - audio

I want to fade a track in and out at specific time codes. For example, I would like to take an audio file, and:
Start it at 100% Volume
Fade it to 20% at 2 seconds
Fade it to 100% at 4 seconds
Fade it to 20% at 6 seconds
Fade it to 100% at 8 seconds
Fade it to 20% at 10 seconds
Fade it to 100% at 12 seconds
Fade it to 0 at 14 seconds
I've been testing this with a constant tone generated by ecasound so that I can open the resulting file in Audacity and see the results visually. As far as I can tell, increasing the amplitude is relative, while decreasing it is not. It seems that if I fade the amplitude up, it affects the relative volume of the whole track and not just at the specific time I set the fade, which is where I'm getting lost.
Example commands
# generate the tone
ecasound -i tone,sine,880,20 -o:tone.wav
# Just the test to see that i can fade start it at 100 and fade it to 20.
ecasound -a:1 -i tone.wav -ea:100 -kl2:1,100,20,2,1 -a:all -o:test_1.mp3
# Fade it out and in
ecasound -a:1 -i tone.wav \
-ea:100 -kl2:1,100,20,2,1 \
-ea:100 -kl2:1,20,100,4,1 \
-a:all -o:test_2.mp3
# Fade it out and in with a peak of 500
ecasound -a:1 -i tone.wav \
-ea:100 -kl2:1,100,20,2,1 \
-ea:100 -kl2:1,20,500,4,1 \
-a:all -o:test_3.mp3
# Fade it out from 500, out, and then back to 500
ecasound -a:1 -i tone.wav \
-ea:100 -kl2:1,500,20,2,1 \
-ea:100 -kl2:1,20,500,4,1 \
-a:all -o:test_4.mp3
# Fade it out from 500, out to a low of 10, and then back to 500
ecasound -a:1 -i tone.wav \
-ea:100 -kl2:1,500,10,2,1 \
-ea:100 -kl2:1,10,500,4,1 \
-a:all -o:test_5.mp3
# Fade it out from 1000, out to a low of 10, and then back to 1000
ecasound -a:1 -i tone.wav \
-ea:100 -kl2:1,1000,10,2,1 \
-ea:100 -kl2:1,10,1000,4,1 \
-a:all -o:test_6.mp3
# The eventual result I'm looking for
ecasound -a:1 -i tone.wav \
-ea:100 -kl2:1,500,20,2,1 \
-ea:100 -kl2:1,20,500,4,1 \
-ea:100 -kl2:1,500,20,6,1 \
-ea:100 -kl2:1,20,500,8,1 \
-ea:100 -kl2:1,500,20,10,1 \
-ea:100 -kl2:1,20,500,12,1 \
-ea:100 -kl2:1,500,0,14,4 \
-a:all -o:test_7.mp3
The Results
The best I can tell from these results is that the amplitude of the whole track is relative to the difference between the low and the peak of all the fading effects. I'm not sure if this result is expected, but it's very confusing.
Also, in the last result (second to last in the image), the fades are no longer taking a full second each. In order to figure out why that may be, I took the final fade-to-zero off and the durations were back to normal. This does not seem like expected behavior.
# "Fixing" the fade durations
ecasound -a:1 -i tone.wav \
-ea:100 -kl2:1,500,20,2,1 \
-ea:100 -kl2:1,20,500,4,1 \
-ea:100 -kl2:1,500,20,6,1 \
-ea:100 -kl2:1,20,500,8,1 \
-ea:100 -kl2:1,500,20,10,1 \
-ea:100 -kl2:1,20,500,12,1 \
-a:all -o:test_8.mp3
As a side note, I've also tried changing the -ea values to the "current" amplitude with every line. It didn't make any difference (no matter what I set -ea to)
I have the very latest installed from git (2.8.1+dev). I had these same issues with 2.7.0, which is why I upgraded and eventually found myself here.
Am I doing this wrong?

-kl2
After a few hours of head scratching, I finally think I have it figured out. The "From" amplitude on every fade needs to be 100. If you are increasing the amplitude, the "To" amplitude is maximum / from * to.
So if you're trying to go from 20 to 100, it's 100 / 20 * 100 or 500. If you're trying to get to 120: 100 / 20 * 120 or 600. I assume this all makes perfect sense to someone, but I was perfectly stumped.
The working example (with a slightly higher bottom range in the middle to demonstrate):
ecasound -a:1 -i tone.wav \
-ea:100 -kl2:1,100,20,2,1 \
-ea:100 -kl2:1,100,500,4,1 \
-ea:100 -kl2:1,100,40,6,1 \
-ea:100 -kl2:1,100,250,8,1 \
-ea:100 -kl2:1,100,20,10,1 \
-ea:100 -kl2:1,100,500,12,1 \
-ea:100 -kl2:1,100,0,14,1 \
-a:all -o:test_7.mp3
And the output:
Keep in mind that these amplitudes are still relative. If you're going from 45% to 90%: 100 / 45 * 90 = 200, and then now if you drop to 20% of the current amplitude, it's actually 18% (.20 * 90), so going back to 100 would be 100 / 18 * 100 = 555.56
-klg
Just as I figured this out, and came here to post, I received a response from the ecasound mailing list. It's not a direct answer to the kl2 issue, but offers an alternative, easier-on-the-brain answer, which is the klg parameter.
-klg:fx-param,low-value,high-value,point_count,pos1,value1,...,posN,valueN
Generic linear envelope. This controller source can be used to map
custom envelopes to chain operator parameters. Number of envelope
points is specified in 'point_count'. Each envelope point consists of
a position and a matching value. Number of pairs must match
'point_count' (i.e. 'N==point_count'). The 'posX' parameters are given
as seconds (from start of the stream). The envelope points are
specified as float values in range '[0,1]'. Before envelope values are
mapped to operator parameters, they are mapped to the target range of
'[low-value,high-value]'. E.g. a value of '0' will set operator
parameter to 'low-value' and a value of '1' will set it to
'high-value'. For the initial segment '[0,pos1]', the envelope will
output value of 'value1' (e.g. 'low-value').
Here's the command to do what I need using klg instead of kl2:
ecasound -a:1 -i:tone.wav -ea:100 \
-klg:1,0,100,14,2,1,3,0.20,4,0.20,5,1,6,1,7,0.40,8,0.40,9,1,10,1,11,0.20,12,0.20,13,1,14,1,15,0 \
-o:test.mp3
The output is exactly the same as the 2nd track on the image.
This resulting command line is definitely a bit harder to read and hence debug, but may actually be easier to generate dynamically. Regardless, I now have 2 working options to resolve this problem.
And finally, here are my notes for how I figured out the coordinates of the klg command. The asterisks are the "points" which are listed in the klg parameter, the numbers at the top are seconds:
0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
1.0 --* *-* *-* *-*
~ \ / \._./ \ / \
0.2 *-* *-* \
0.0 *----------
I hope this helps someone save at least the amount of hair that i've lost scratching my head.

Related

How to convert raw YUV image to jpg

I have a raw image that was taken with v4l2-ctl after the camera had been setup like:
# media-ctl -d /dev/media0 -l "'rzg2l_csi2 10830400.csi2':1 -> 'CRU output':0 [1]"
# media-ctl -d /dev/media0 -V "'rzg2l_csi2 10830400.csi2':1 [fmt:UYVY8_2X8/1280x960 field:none]"
# media-ctl -d /dev/media0 -V "'ov5645 0-003c':0 [fmt:UYVY8_2X8/1280x960 field:none]"
and then the picture got snapped with:
# v4l2-ctl --device /dev/video0 --stream-mmap --stream-to=frame.raw --stream-count=1
now I've tried multiple methods to convert this into a jpeg but nothing seems to yield the expected output
the raw file can be downloaded here: https://drive.google.com/file/d/1VqXnrJDYbzdtSsWfTlm2mX9rl1-Rl_7F/view?usp=sharing
I tried out the following command:
convert -verbose -size 1280x960 UYVY:frame.raw frame.bmp
which I found on Converting from YUV(UYVY) to RGB using imagemagick
but it doesn't do the trick
Your frame is 2457600 bytes and your pixel dimensions are 1280x960, so you have:
bits per pixel = 2457600 * 8 / (1280 * 960) = 16
You can get a list of the pixel formats that ffmpeg supports using:
ffmpeg -pix_fmts 2> /dev/null
Sample Output
FLAGS NAME NB_COMPONENTS BITS_PER_PIXEL
-----
IO... yuv420p 3 12
IO... yuyv422 3 16
IO... rgb24 3 24
IO... bgr24 3 24
IO... yuv422p 3 16
IO... yuv444p 3 24
IO... yuv410p 3 9
...
...
That means you can get a list of pixel formats that contain Y, U and V with 16 bits per pixel like this:
ffmpeg -pix_fmts 2> /dev/null | awk '/y/ && /u/ && /16$/ {print}'
IO... yuyv422 3 16
IO... yuv422p 3 16
IO... yuvj422p 3 16
IO... uyvy422 3 16
IO... yuv440p 3 16
IO... yuvj440p 3 16
IO... yvyu422 3 16
Now you can run a loop, iterating over all the 16-bit per pixel YUV formats and see what ffmpeg makes of your image - naming each result after the format so you can identify which is which:
ffmpeg -pix_fmts 2> /dev/null |
awk '/y/ && /u/ && /16$/ {print $2}' |
while read f; do
ffmpeg -y -s:v 1280x960 -pix_fmt $f -i frame.raw $f.jpg
done
That gives you these files:
-rw-r--r-- 1 mark staff 304916 3 Feb 09:38 yuv440p.jpg
-rw-r--r-- 1 mark staff 227123 3 Feb 09:38 yuvj422p.jpg
-rw-r--r-- 1 mark staff 39543 3 Feb 09:38 yuyv422.jpg
-rw-r--r-- 1 mark staff 39545 3 Feb 09:38 yvyu422.jpg
And I guess that yuyv422.jpg is your image, so that means you can extract it with:
ffmpeg -y -s:v 1280x960 -pix_fmt yuyv422 -i frame.raw result.jpg
If you wanted to do that with ImageMagick, you could do something like this:
#!/bin/bash
python3 <<EOF
import numpy as np
h, w = 960, 1280
# Load raw file into Numpy array
raw = np.fromfile('frame.raw', np.uint8)
raw[0::2].tofile('Y') # Starting at the 1st byte, write every 2nd byte to file "Y"
raw[1::4].tofile('U') # Starting at the 2nd byte, write every 4th byte to file "U"
raw[3::4].tofile('V') # Starting at the 3rd byte, write every 4th byte to file "V"
EOF
# Load the Y channel, then the U and V channels forcibly resizing them, then combine and go to sRGB
magick -depth 8 -size 1280x960 gray:Y \
\( -size 640x960 gray:U gray:V -resize 1280x960\! \) \
-set colorspace YUV -combine -colorspace sRGB result.jpg
If yo don't like/have Python, that part can be replaced with some basic C as follows:
#include <stdint.h>
#include <stdio.h>
// Split YUYV file called "frame.raw" into separate channels with filenames "Y", "U" and "V"
// Compile with: clang -O3 splitter.c -o splitter
int main(){
FILE *in, *Y, *U, *V;
uint8_t buffer[4];
size_t bytesRead;
// Open input file and 1 output file per channel
in = fopen("frame.raw", "rb");
Y = fopen("Y", "wb");
U = fopen("U", "wb");
V = fopen("V", "wb");
// read up to sizeof(buffer) bytes
while ((bytesRead = fread(buffer, 1, sizeof(buffer), in)) > 0)
{
fputc(buffer[0], Y);
fputc(buffer[1], U);
fputc(buffer[2], Y);
fputc(buffer[3], V);
}
}
Having had so much fun doing ffmpeg, Python, and C versions, I thought I'd try just doing it in the shell - converting bytes to lines and so I could pick alternate lines instead of alternate bytes. This works the same as the above:
#!/bin/bash
# Build JPEG image from YUYV image with packed bytes in order YUYVYUYV...
# Use "xxd" to convert bytes into lines, then extract alternate lines - which is easier than extracting bytes
H=960
W=1280
INPUT="frame.raw"
# Take top byte of every uint16 and put into "Y.pgm"
xxd -c1 -p "$INPUT" | sed -n 'p;n' | xxd -r -p | magick -size ${W}x${H} -depth 8 gray:- Y.pgm
# Take bottom byte of every 2nd uint16, starting at the 1st, resize up to full width and put into "U.pgm"
xxd -c1 -p "$INPUT" | sed -n 'n;p' | sed -n 'p;n' | xxd -r -p | magick -size $((W/2))x${H} -depth 8 gray:- -resize ${W}x${H}\! U.pgm
# Take bottom byte of every 2nd uint16, starting at the 2nd, resize up to full width and put into "V.pgm"
xxd -c1 -p "$INPUT" | sed -n 'n;p' | sed -n 'n;p' | xxd -r -p | magick -size $((W/2))x${H} -depth 8 gray:- -resize ${W}x${H}\! V.pgm
# Load the 3 channels, combine and convert to JPEG
magick {Y,U,V}.pgm -set colorspace YUV -combine -colorspace sRGB result.jpg
# Remove litter
rm {Y,U,V}.pgm
As regards colour cast removal, as I said in the comments, the " normal" way, AFAIK, is to get the average colour of the image and invert its Hue then blend that "negated cast" back with the original image to offset the original colour cast. Here is a crude attempt - if anyone knows better please ping me!
Step 1: Get average colour cast
magick result.jpg -resize 1x1\! cast.png
Step 2: Invert the cast
magick cast.png -modulate 100,100,0 correction.png
Step 3: Blend the original with the correction and brighten maybe
magick result.jpg correction.png -define compose:args=50,50 -compose blend -composite -auto-level result.jpg
Here are the original and corrected versions:
Obviously you can change the percentages for different degrees of "correction".

Script is not working. What am I doing wrong?

First off I found this guide, which details exactly what I need.
https://imagemagick.org/script/connected-components.php
For the life of me I cannot get this to work. Anyone have any idea?
I've tried a bunch of variations of the scripts listed in the guide.
Also when I run convert /var/www/mailtovoice/audrey/sean_look_grey.png -define connected-components:verbose=true -connected-components 8 /var/www/mailtovoice/audrey/sean_look4.png
I get 1000s of objects. When I converted it to an image with just 3 objects I get 100s.
Mark has the right idea, but the solution is much simpler than he posted, since ImageMagick -connected-components can do the filtering and output directly.
input:
Unix line endings (for windows use ^ rather than \ )
convert image.png \
-define connected-components:area-threshold=100 \
-define connected-components:mean-color=true \
-connected-components 4 \
result.png
The method suggested by Fred (#fmw42) is far simpler and preferable to that shown in this answer, so all but die-hard enthusiasts should use Fred's answer. Rather than delete mine, I will leave it showing as it could form the basis for other more demanding/involved processing.
This is a rather funny way to do it... find all the blobs. i.e. connected components:
convert spotty.png -define connected-components:verbose=true -connected-components 4 null:
which gives you something like this but with 2,000+ lines:
Objects (id: bounding-box centroid area mean-color):
0: 860x482+0+0 431.5,239.7 405738 gray(0)
800: 43x263+252+219 265.9,350.5 2458 gray(255)
2: 21x226+276+0 288.9,111.2 1540 gray(255)
2216: 5x16+107+445 109.3,452.9 65 gray(255)
910: 7x15+276+228 279.0,234.5 63 gray(255)
491: 7x14+651+150 654.1,156.6 54 gray(255)
1207: 7x9+735+282 737.9,285.8 53 gray(255)
2313: 6x9+147+457 149.6,460.9 48 gray(255)
985: 8x9+754+238 757.3,242.0 48 gray(255)
...
...
Now look for all the ones with a size (second-to-last field) less than 1000 using awk and print the region:
convert spotty.png \
-define connected-components:verbose=true \
-connected-components 4 null: |
awk -v thresh=1000 'NR>1 && $(NF-1)<thresh{print " -region " $2 " -colorize 100%"}'
Output
-region 5x16+107+445 -colorize 100%
-region 7x15+276+228 -colorize 100%
-region 7x14+651+150 -colorize 100%
-region 7x9+735+282 -colorize 100%
...
...
Now reload the original image, set the fill colour for colorised regions to red and regenerate the list of regions to be filled exactly as above:
convert spotty.png -fill red $(convert spotty.png -define connected-components:verbose=true -connected-components 4 null: | awk -v thresh=1000 'NR>1 && $(NF-1)<thresh{print " -region " $2 " -colorize 100%"}' ) result.png
The command generated boils down to:
convert spotty.png -threshold 50% -fill red \
-region 56x16+107+445 -colorize 100% \
-region 70x15+276+228 -colorize 100% \
-region ... -colorize 100% \
...
...
result.png

What language is this old program written in?

"Hi, could you rewrite something for me", my boss said, "some legacy code". Yeah, legacy code written somewhere in early Mesozoic.
I have 30 hours left, and I still don't know, what kind of syntax is this! VHLD? VBA? Program is dedicated do to something with audio files, and dedicated to run under DOS.
Could you give me a hint what is this? How to compile it?
Code snippet:
enter \ Load - main screen
empty forth definitions decimal
application warning on
: TITLE ." KCS version 0.8 28-Jan-06" cr ;
cr .( Compiling: ) title 2 load
cr .( Save to disk? ) y/n
[if]
\ pad reserve # + 256 + limit s0 # - + set-limit
turnkey program KCS
[then]
\ Load - defaults
variable RESERVE 0 reserve ! \ reserved memory tally
defer ?BREAK ' noop is ?break \ break check off
defer SET-IO ' bios-io is set-io \ default console mode
defer ERRFIX ' noop is errfix \ reset on-error handler
blk # 1+ #screens 1- thru \ load electives & application
' (?break) is ?break \ enable user break
\ ' dos-io is set-io \ enable console redirection
\ ' deloutfile +is errfix \ delete outfile on error
\ wrtchk off \ disable overwrite check
\ Load - electives
1 fload DOSLIB \ load DOSLIB library
_Errors \ error handler
_Inout1 \ number output
_Inout2 \ string & number input
_String1 \ basic strings
\ _String2 \ extra strings
_Parsing \ command-line parsing
_Fileprims \ file primitives
_Files \ default files
_Bufinfile \ buffered input file
_Bufoutfile \ buffered output file
\ DECODE
\ Convert wave file to program
: DECODE ( -- )
0. decodecount 2! 0. paritycount 2! 0 errors !
skipheader
begin
['] decodebyte 1 ?catch 0=
while ( not EOF )
conout # if emit else writechar then
1 decodecount m+!
repeat
.decoded ;
\ SETMODE
\ Select Kansas City Standard or Processor Tech. CUTS mode
: SETMODE ( -- )
mode # if ( CUTS )
8 to databits 2 sbits ! 4 speed ! parity off pace off
nullcnt off
['] 0bit-sqr-cuts is 0bit-sqr ['] 1bit-sqr-cuts is 1bit-sqr
['] 0bit-sin-cuts is 0bit-sin ['] 1bit-sin-cuts is 1bit-sin
['] seekstart-cuts is seekstart ['] getbit-cuts is getbit
else ( KCS )
['] 0bit-sqr-kcs is 0bit-sqr ['] 1bit-sqr-kcs is 1bit-sqr
['] 0bit-sin-kcs is 0bit-sin ['] 1bit-sin-kcs is 1bit-sin
['] seekstart-kcs is seekstart ['] getbit-kcs is getbit
then ;
\ (RUN)
\ Run application
: (RUN) ( -- )
setmode
r/o openinfile
decoding # if
conout # 0= if r/w makeoutfile then
cr decode
else
r/w makeoutfile
cr encode
then
closefiles
;
\ DEFAULTS
\ Set application defaults
: DEFAULTS ( -- )
mode off decoding on strict off ignore off conout off
1 speed ! 2 sbits ! parity off 5 leadtime ! 10 nullchar !
pace off nullcnt off wave off tone off inverted off ;
defaults
\ RUN PROGRAM
\ Run application with error handling
: RUN ( -- )
['] (run) catch ?dup if >r errfix r> throw then ;
\ Main
: PROGRAM ( -- )
set-io \ set console mode
defaults \ set defaults
cr title \ show application name
parsecmd \ get options/filenames
run \ run application
cr ." done" \ show success
;
It's written in Forth, probably the DX-Forth dialect. The program decodes and encodes WAVE files that contain data in the Kansas City standard format. This format was used to record data on cassette tapes on early S-100 CP/M machines. Searching the web reveals that there was a program written in DX-Forth that could decode and encode WAVE files in this format, so I'm guessing it's the program you've be tasked with rewriting.
Rather than rewriting this code however, a simpler thing to do would be to use existing free software that already does the job. For example there's a program called py-kcs written in Python that should be a functional replacement and one called hx-kcs written in Haxe that can do decoding.

Weka command line attributes arguments

On the command line, I'm able to get this rolling with no problem:
java weka.Run weka.classifiers.timeseries.WekaForecaster -W
"weka.classifiers.functions.MultilayerPerceptron -L 0.01 -M 0.2 -N 500 -V 0 -S 0 -E 20 -H 20 " -t "C:\MyFile.arff" -F DirectionNumeric -L 1 -M 3 -prime 3 -horizon 6 -holdout 100 -G TradeDay -dayofweek -weekend -future
But once I try to put the skip list, I start to get errors saying that it's missing a date that is not in the skip list even though the date is in fact on it:
java weka.Run weka.classifiers.timeseries.WekaForecaster -W "weka.classifiers.functions.MultilayerPerceptron -L 0.01 -M 0.2 -N 500 -V 0 -S 0 -E 20 -H 20 " -t "C:\MyFile.arff" -F DirectionNumeric -L 1 -M 3 -prime 3 -horizon 6 -holdout 100 -G TradeDay -dayofweek -weekend -future -skip ""2014-06-07#yyyy-MM-dd, 2014-06-12"
Does anybody knows how to get this working? Weka is low on documentation as far as I know.
Thank's in advance!
Forget it. I got it, the problem was the 's' must be in capital letters:
-Skip
instead of
-skip.

Weka, SVM technique output

I am working with SVM at Weka
I have some data and I try SVM (I tried different values of C) technique to analize the data. But the output has totally confused me, that is why I hope some help.
This is the output for a polynomial kernel of degree 1:
Scheme:weka.classifiers.meta.CVParameterSelection -P "C 0.001 10.0 5.0" -X 10 -S 1 -W weka.classifiers.functions.SMO -- -C 0.7 -L 0.001 -P 1.0E-12 -N 0 -V -1 -W 1 -K "weka.classifiers.functions.supportVector.PolyKernel -C 250007 -E 1.0"
Classifier Options: -C 7.5003 -L 0.001 -P 1.0E-12 -N 0 -V -1 -W 1 -K "weka.classifiers.functions.supportVector.PolyKernel -C 250007 -E 1.0"
=== Summary ===
Correctly Classified Instances 83 79.0476 %
Incorrectly Classified Instances 22 20.9524 %
Kappa statistic 0.6555
Mean absolute error 0.0487
Root mean squared error 0.1549
Relative absolute error 91.5633 %
Root relative squared error 100.2828 %
Total Number of Instances 105
This is the output for a polynomial kernel of degree 2:
Scheme:weka.classifiers.meta.CVParameterSelection -P "C 0.001 10.0 5.0" -X 10 -S 1 -W weka.classifiers.functions.SMO -- -C 0.7 -L 0.001 -P 1.0E-12 -N 0 -V -1 -W 1 -K "weka.classifiers.functions.supportVector.PolyKernel -C 250007 -E 2.0"
Classifier Options: -C 2.5008 -L 0.001 -P 1.0E-12 -N 0 -V -1 -W 1 -K "weka.classifiers.functions.supportVector.PolyKernel -C 250007 -E 2.0"
=== Summary ===
Correctly Classified Instances 87 82.8571 %
Incorrectly Classified Instances 18 17.1429 %
Kappa statistic 0.7236
Mean absolute error 0.0486
Root mean squared error 0.1547
Relative absolute error 91.4748 %
Root relative squared error 100.1845 %
Total Number of Instances 105
This is the output for a gaussian kernel and gamma value of 1.0:
Scheme:weka.classifiers.meta.CVParameterSelection -P "C 0.001 10.0 5.0" -X 10 -S 1 -W weka.classifiers.functions.SMO -- -C 0.7 -L 0.001 -P 1.0E-12 -N 0 -V -1 -W 1 -K "weka.classifiers.functions.supportVector.RBFKernel -C 250007 -G 1.0"
Classifier Options: -C 2.5008 -L 0.001 -P 1.0E-12 -N 0 -V -1 -W 1 -K "weka.classifiers.functions.supportVector.RBFKernel -C 250007 -G 1.0"
=== Summary ===
Correctly Classified Instances 87 82.8571 %
Incorrectly Classified Instances 18 17.1429 %
Kappa statistic 0.721
Mean absolute error 0.0486
Root mean squared error 0.1547
Relative absolute error 91.4571 %
Root relative squared error 100.1651 %
Total Number of Instances 105
These are my questions:
Why the classifiers at “Classifier Options: -Cxxxxx” have different values of C? I think it is related to the values of C that I am checking with “C 0.001 10.0 5.0”, but I may be wrong and I may be getting wrong conclusions. I think that with “C 0.001 10.0 5.0” it tries the values 0.001, 0.01, 0.1, 1.0 and 10.0. If that is true why the values of C are: 7.5003 and 2.5008??
The percentage of the Correctly Classified Instances is very similar in all of the different runs, I don’t understand why… What does it mean? If it were 12% I would think SVM was not a proper technique (it wasn't linearly separable) but with 80% (no or little variations after changing the parameters) I don’t know what to think…
If I check the data in the “Visualize” of Weka the data doesn’t seem linearly separable but due to the conversion of a bigger number of dimensions when I use SVM I don’t think it is possible to get conclusions from the visualize.
1) Yes you use CVParameterSelection which trys different parameters in your case from 0.001 to 10 in 5 steps. The steps would be 0.001 + k * (10-0.001)/4) because your first step is allready defined as 0.001. If you round the following values (for k= 0/1/2/3/4) you see that they fit.
Step 1) 0.001
Step 2) 2.50075
Step 3) 5.005
Step 4) 7.50025
Step 5) 10.0
2) If you would have 12% accuracy there would be something really strange. Random classification (assuming you have balanced data) would result in 50%. I cannot tell you if 82% is a good result because i don't know about your data.
3) To your question about linar separability. Thats exactly why the SVM is so good. SVM with the right Kernel transforms your data into a higher featurespace to get rid of the non-separability. An RBF kernel can transform your data even into an infinite-dimensional feature space. Thats why a perfect linar separation is allways possible. At this point overfitting can occur. To avoid that and reach a good generalisation you have your complexity parameter C.
Here you can read more in a good stackexchange post about the last point
https://stats.stackexchange.com/questions/80398/how-can-svm-find-an-infinite-feature-space-where-linear-separation-is-always-p

Resources