IPB

Welcome Guest ( Log In | Register )

15 Pages V  « < 9 10 11 12 13 > »   
Reply to this topicStart new topic
New FLAC encoder
guruboolez
post Oct 5 2006, 17:28
Post #251





Group: Members (Donating)
Posts: 3474
Joined: 7-November 01
From: Strasbourg (France)
Member No.: 420



Thank you very much Wombat smile.gif

May I suggest to Justin that the first official release of flake should come with a small warning (inside the documentation and/or inside flake.exe with -h switch) about possible hardware players' issues with -11 & -12 setting?
Go to the top of the page
+Quote Post
Josef Pohm
post Oct 5 2006, 17:32
Post #252





Group: Members
Posts: 40
Joined: 2-April 06
Member No.: 29099



QUOTE (Wombat @ Oct 5 2006, 18:22) *
Exactly how you predicted. -10 still is playable. From -11 on it stutters.


To my little knoledge decoding speed of lossless codecs mostly depends on the maximum number of predictor order used.

Flake -5 uses 8 max predictor order, like Flac -5 (and Garf version of Flac).
Flake -8,-9 and -10 uses 12 max predictor order like Flac -8 (and Garf version of Flac).
Flake -11 and -12 uses 32, so it requires much more decoding power.

I hope that's correct.
Go to the top of the page
+Quote Post
jcoalson
post Oct 5 2006, 18:03
Post #253


FLAC Developer


Group: Developer
Posts: 1526
Joined: 27-February 02
Member No.: 1408



I think I am going to officially limit the subset to 12-order LPC for 44.1kHz to head off problems like this. with FLAC at that sample rate, using high orders like that is usually a poor tradeoff and letting users do this without a warning is just going to create confusion. this goes for flac too which currently allows -l 32 without a warning.

most of the compression advantage of flake over FLAC 1.1.2 has already been incorporated into FLAC 1.1.3. the extra compression from 32-order LPC is minimal.

Josh
Go to the top of the page
+Quote Post
wisodev
post Oct 5 2006, 20:39
Post #254





Group: Developer
Posts: 123
Joined: 31-January 06
Member No.: 27439



Flake (Win32) from SVN revision 104 available:

Download from my Website

or use direct links:

Download binarys:
flake-svn-r104-win32-bin.zip

Download sources:
flake-svn-r104-win32-src.zip

NOTE: I have added my small patch to code (quality or speed is not affected), can be found here, the sources are already patched (this patch comes from my local subversion repository and is not related with sf.net subversion).

wisodev


--------------------
http://code.google.com/p/wavtoac3encoder/
Go to the top of the page
+Quote Post
fairway
post Oct 5 2006, 21:50
Post #255





Group: Members
Posts: 81
Joined: 4-July 02
Member No.: 2477



QUOTE (Josef Pohm @ Oct 5 2006, 16:32) *
QUOTE (Wombat @ Oct 5 2006, 18:22) *

Exactly how you predicted. -10 still is playable. From -11 on it stutters.


To my little knoledge decoding speed of lossless codecs mostly depends on the maximum number of predictor order used.

Flake -5 uses 8 max predictor order, like Flac -5 (and Garf version of Flac).
Flake -8,-9 and -10 uses 12 max predictor order like Flac -8 (and Garf version of Flac).


Though seeking with a flake encoded file is still significantly slower than with a FLAC (reference encoder) encoded file (try it in winamp with the default flac plugin).
Go to the top of the page
+Quote Post
Justin Ruggles
post Oct 6 2006, 02:07
Post #256





Group: Developer
Posts: 165
Joined: 3-June 06
From: Raleigh, NC
Member No.: 31393



QUOTE (guruboolez @ Oct 5 2006, 12:28) *
Thank you very much Wombat smile.gif

May I suggest to Justin that the first official release of flake should come with a small warning (inside the documentation and/or inside flake.exe with -h switch) about possible hardware players' issues with -11 & -12 setting?

Okay, that sounds like a good idea.

QUOTE (jcoalson @ Oct 5 2006, 13:03) *
I think I am going to officially limit the subset to 12-order LPC for 44.1kHz to head off problems like this. with FLAC at that sample rate, using high orders like that is usually a poor tradeoff and letting users do this without a warning is just going to create confusion. this goes for flac too which currently allows -l 32 without a warning.

Cool. Based on this, and the hardware decoding issues, I'll go ahead and add a separate warning for any lpc order over 12 for any sample rate up to 48kHz. Once the official subset standard changes, I'll change Flake's warnings accordingly.

-Justin
Go to the top of the page
+Quote Post
JWolf
post Oct 7 2006, 05:02
Post #257





Group: Members
Posts: 65
Joined: 3-May 05
Member No.: 21842



QUOTE (Wombat @ Oct 5 2006, 11:50) *
Ah, oh. I see a problem. Does -12 take that much processing power or isnīt it 100% compatible to flac 1.1.2 decoding anymore?
My Squeezebox canīt play flake -12 on all titles. It stutters around. Flake -5 for example is fine.

Edit:
The compile Garf offered a while back works flawlessly on the Squeezebox and has higher compression already as standard 1.1.2.


Using the current version of FLAKE, I was able to play -12 compressed files on my Rio Karma with no hiccups.

Jon
Go to the top of the page
+Quote Post
jcoalson
post Oct 7 2006, 07:51
Post #258


FLAC Developer


Group: Developer
Posts: 1526
Joined: 27-February 02
Member No.: 1408



QUOTE (jcoalson @ Oct 5 2006, 12:03) *
I think I am going to officially limit the subset to 12-order LPC for 44.1kHz to head off problems like this. with FLAC at that sample rate, using high orders like that is usually a poor tradeoff and letting users do this without a warning is just going to create confusion. this goes for flac too which currently allows -l 32 without a warning.

it is done. smile.gif

the new limits: if the sample rate is <=48kHz, max blocksize = 4608 and max LPC order = 12. all the tests I did showed that 32-order LPC got <0.1% more compression (usually a lot less).

http://flac.cvs.sourceforge.net/*checkout*...mat.html#subset

Josh
Go to the top of the page
+Quote Post
wisodev
post Oct 7 2006, 10:15
Post #259





Group: Developer
Posts: 123
Joined: 31-January 06
Member No.: 27439



I have builded a faster FLAKE binary from rev. 104 but it needs some testing.

On one of my test files encoding time has droped from 193.468 seconds (previous r104 build) to 173.906 seconds (test r104 build) using -12 command-line option.

Download test binary:
flake_r104_test.zip

wisodev


--------------------
http://code.google.com/p/wavtoac3encoder/
Go to the top of the page
+Quote Post
MedO
post Oct 7 2006, 12:25
Post #260





Group: Members
Posts: 341
Joined: 24-August 05
Member No.: 24095



QUOTE (wisodev @ Oct 7 2006, 11:15) *
I have builded a faster FLAKE binary from rev. 104 but it needs some testing.

On one of my test files encoding time has droped from 193.468 seconds (previous r104 build) to 173.906 seconds (test r104 build) using -12 command-line option.

Download test binary:
flake_r104_test.zip

wisodev


Your test compile is a bit faster than mine on my machine (Celeron M 1,4Ghz). I can't give any good values, though, because I already got several seconds difference when running my own build twice, so the measurement is not very reliable.
Go to the top of the page
+Quote Post
Synthetic Soul
post Oct 7 2006, 19:00
Post #261





Group: Super Moderator
Posts: 4887
Joined: 12-August 04
From: Exeter, UK
Member No.: 16217



QUOTE (wisodev @ Oct 7 2006, 10:15) *
I have builded a faster FLAKE binary from rev. 104 but it needs some testing.

On one of my test files encoding time has droped from 193.468 seconds (previous r104 build) to 173.906 seconds (test r104 build) using -12 command-line option.
Here's some results for my "FLAC" corpus:

CODE
Setting       R104    R104 Test   Diff
======================================
-10       286.726s     274.561s    96%
-11       375.687s     347.035s    92%
-12      1002.105s     914.239s    91%

Edit: Here's the figures for my MinGW compile:

CODE
Setting  MinGW R104   R104 Test   Diff
======================================
-10        394.015s    274.561s    70%
-11        486.764s    347.035s    71%
-12       1322.178s    914.239s    69%

I don't think I'll bother anymore! biggrin.gif Excellent work wisodev.

NB: Timings were recorded using TIMER, and CPU-only times are reported.

This post has been edited by Synthetic Soul: Oct 7 2006, 20:32


--------------------
I'm on a horse.
Go to the top of the page
+Quote Post
Justin Ruggles
post Oct 8 2006, 04:57
Post #262





Group: Developer
Posts: 165
Joined: 3-June 06
From: Raleigh, NC
Member No.: 31393



QUOTE (jcoalson @ Oct 7 2006, 02:51) *
QUOTE (jcoalson @ Oct 5 2006, 12:03) *
I think I am going to officially limit the subset to 12-order LPC for 44.1kHz to head off problems like this. with FLAC at that sample rate, using high orders like that is usually a poor tradeoff and letting users do this without a warning is just going to create confusion. this goes for flac too which currently allows -l 32 without a warning.

it is done. smile.gif

the new limits: if the sample rate is <=48kHz, max blocksize = 4608 and max LPC order = 12. all the tests I did showed that 32-order LPC got <0.1% more compression (usually a lot less).

http://flac.cvs.sourceforge.net/*checkout*...mat.html#subset

Josh

Splendid. I have modified the Flake warning message output and the return code of the flake_validate_params function to reflect the new standard.
Go to the top of the page
+Quote Post
iGold
post Oct 11 2006, 21:20
Post #263





Group: Members
Posts: 139
Joined: 23-December 05
Member No.: 26599



I checkout rev.107 from SVN and compile it myself under x86_64 Ubuntu. While encoding disc image I see:
QUOTE
Signed 16-bit 44100 Hz stereo
samples: 116712120 (0m16.961s)

If I try to compile this test code:
CODE
int th, tm, ts, tms;
tms = 116712120 * 1000 / 44100;
I get two "integer overflow" warnings.

I think int is too small here (in flake.c at line 447).
Go to the top of the page
+Quote Post
Justin Ruggles
post Oct 11 2006, 22:14
Post #264





Group: Developer
Posts: 165
Joined: 3-June 06
From: Raleigh, NC
Member No.: 31393



QUOTE (iGold @ Oct 11 2006, 16:20) *
I checkout rev.107 from SVN and compile it myself under x86_64 Ubuntu. While encoding disc image I see:
QUOTE
Signed 16-bit 44100 Hz stereo
samples: 116712120 (0m16.961s)

If I try to compile this test code:
CODE
int th, tm, ts, tms;
tms = 116712120 * 1000 / 44100;
I get two "integer overflow" warnings.

I think int is too small here (in flake.c at line 447).

Thanks. Fixed.
Also, anyone can submit bug reports on Flake's Sourceforge project page. Getting bug reports via HA makes me feel a little guilty for taking up space with small fixes. They are appreciated either way though. smile.gif
Go to the top of the page
+Quote Post
wisodev
post Oct 12 2006, 19:16
Post #265





Group: Developer
Posts: 123
Joined: 31-January 06
Member No.: 27439



Flake (Win32) from SVN revision 108 available:

Download from my Website

or use direct links:

Download binarys:
flake-svn-r108-win32-bin.zip

Download sources:
flake-svn-r108-win32-src.zip

wisodev


--------------------
http://code.google.com/p/wavtoac3encoder/
Go to the top of the page
+Quote Post
Justin Ruggles
post Oct 15 2006, 18:31
Post #266





Group: Developer
Posts: 165
Joined: 3-June 06
From: Raleigh, NC
Member No.: 31393



QUOTE (Will Fisher @ Sep 22 2006, 20:01) *
although i ran into a couple of problems compiling.

Would it be too much of a problem to put my changes into the code, to keep it portable across compilers?

optimize.c line 219 replaced with: uint32_t bits[32]; (where 32 used to be levels. MSVC doesn't like non-constant sizes for these things.) I am sure that 32 is as large as levels gets.

in encode.c flake_set_defaults, msvc doen't like this syntax:
foo = ((int[]){1,2,3})[2];
so i defined all these "nameless" arrays as ones with names, so it becomes:
int sel[] = {1,2,3};
foo = sel[2];

thanks,
will

Both MSVC issues have now been fixed.

Also, I am almost done with a new website for Flake. The only thing left is API documentation and benchmarks. I am putting in a link to Synthetic Soul's lossless benchmarks, but it would also be nice to have more extensive tests to better illustrate the differences between the compression levels. I'm not so worried anymore about detailed comparisons to the reference encoder because Synthetic Soul's tests give a good enough overview. Since my computer is quite slow, it would really help me out if someone could benchmark the current SVN version of Flake using the rw corpus at all compression levels. Also, adding in tests for "-8 -v 1", "-12 -v 1", and "-99" would be useful. Corpus totals would be better than file-by-file results.

Thanks!
Justin
Go to the top of the page
+Quote Post
Will Fisher
post Oct 16 2006, 10:32
Post #267





Group: Members
Posts: 17
Joined: 2-October 03
Member No.: 9121



QUOTE (Justin Ruggles @ Oct 15 2006, 09:31) *
Both MSVC issues have now been fixed.
Excellent, thanks smile.gif

I have included my enc_flac plugin (sources are attached somewhere in this thread =) built with wisodevs libFlake r108 to the beta branch of Winamp.

If it gets a good response from our beta team and QA department (and I can't see why it wouldn't) maybe we'll put it in a subsequent version of winamp.
Go to the top of the page
+Quote Post
Synthetic Soul
post Oct 17 2006, 16:38
Post #268





Group: Super Moderator
Posts: 4887
Joined: 12-August 04
From: Exeter, UK
Member No.: 16217



QUOTE (Justin Ruggles @ Oct 15 2006, 18:31) *
Since my computer is quite slow, it would really help me out if someone could benchmark the current SVN version of Flake using the rw corpus at all compression levels. Also, adding in tests for "-8 -v 1", "-12 -v 1", and "-99" would be useful. Corpus totals would be better than file-by-file results.
Has anyone provided this yet?

I don't mind running the tests if no-one else will. My machine isn't hugely fast (Athlon XP 2400+, 512MB RAM, Win2K) but it's OK, and I will need a compile from wisodev as I have proved already that my compiles are far inferior to his.


--------------------
I'm on a horse.
Go to the top of the page
+Quote Post
wisodev
post Oct 17 2006, 17:43
Post #269





Group: Developer
Posts: 123
Joined: 31-January 06
Member No.: 27439



QUOTE (Synthetic Soul @ Oct 17 2006, 17:38) *
QUOTE (Justin Ruggles @ Oct 15 2006, 18:31) *
Since my computer is quite slow, it would really help me out if someone could benchmark the current SVN version of Flake using the rw corpus at all compression levels. Also, adding in tests for "-8 -v 1", "-12 -v 1", and "-99" would be useful. Corpus totals would be better than file-by-file results.
Has anyone provided this yet?

I don't mind running the tests if no-one else will. My machine isn't hugely fast (Athlon XP 2400+, 512MB RAM, Win2K) but it's OK, and I will need a compile from wisodev as I have proved already that my compiles are far inferior to his.


I will provide fresh compile in few hours including new experimental build using P3 optimizations (using only compiler options - not assembly optimized!!!) witch seems to be even faster then the last one.

This post has been edited by wisodev: Oct 17 2006, 17:48


--------------------
http://code.google.com/p/wavtoac3encoder/
Go to the top of the page
+Quote Post
wisodev
post Oct 17 2006, 20:34
Post #270





Group: Developer
Posts: 123
Joined: 31-January 06
Member No.: 27439



Flake (Win32) from SVN revision 110 available:

Download from my Website

or use direct links:

Download binarys:
flake-svn-r110-win32-bin.zip

Download sources:
flake-svn-r110-win32-src.zip

wisodev

This post has been edited by wisodev: Nov 29 2006, 17:41


--------------------
http://code.google.com/p/wavtoac3encoder/
Go to the top of the page
+Quote Post
Synthetic Soul
post Oct 17 2006, 20:48
Post #271





Group: Super Moderator
Posts: 4887
Joined: 12-August 04
From: Exeter, UK
Member No.: 16217



Thanks wisodev. smile.gif

I have an AMD XP CPU. Should I be looking at /org/flake.exe, /p3/flake.exe or /flake.exe?


--------------------
I'm on a horse.
Go to the top of the page
+Quote Post
MedO
post Oct 17 2006, 21:17
Post #272





Group: Members
Posts: 341
Joined: 24-August 05
Member No.: 24095



Something interesting here, I noticed that -5 often gives better results than -6, in fact, the size is often similar to that of -7 and -8. Fiddling with the settings a bit, I noticed that this is because of the setting "order method: estimate" which seems to produce better results than "2-Level" and sometimes better than "4-Level" as well.

I didn't test on many files, so this might be a coincidence, but on the few files I tested the commandline "flake -8 -m 1" was always faster and always produced bitrates similar or better than "flake -8". Might be worth investigating...

Edit: I just did a short test with the album "Supertramp - Some Things Never Change", comparing the commandlines "-8" and "-8 -m 1".
"-8 -m 1" was of course always way faster, and compressed 8 of the 12 files better than "-8". The differences in bitrate were quite small though, around 0.1-0.2kbps average.

This post has been edited by MedO: Oct 17 2006, 22:16
Go to the top of the page
+Quote Post
PrakashP
post Oct 17 2006, 21:46
Post #273





Group: Members
Posts: 28
Joined: 5-November 05
Member No.: 25575



@wisodev

I would be interested what compiler flags you use (and which compiler). Have you added asm to the sources?
Go to the top of the page
+Quote Post
MedO
post Oct 17 2006, 22:01
Post #274





Group: Members
Posts: 341
Joined: 24-August 05
Member No.: 24095



Also, I still get this time bug when encoding with wisodev's latest build (all binaries show this)
CODE
Signed 16-bit 44100 Hz stereo
samples: 13265868 (0m8.638s)


I thought this was solved?
Go to the top of the page
+Quote Post
Justin Ruggles
post Oct 18 2006, 02:47
Post #275





Group: Developer
Posts: 165
Joined: 3-June 06
From: Raleigh, NC
Member No.: 31393



QUOTE (MedO @ Oct 17 2006, 17:01) *
Also, I still get this time bug when encoding with wisodev's latest build (all binaries show this)
CODE
Signed 16-bit 44100 Hz stereo
samples: 13265868 (0m8.638s)


I thought this was solved?

I did too...sorry. I just committed a 2nd attempt, which seems to work for me. I just tested it on a 11 million sample wav and it correctly reported around 4 minutes.
-Justin


QUOTE (MedO @ Oct 17 2006, 16:17) *
Something interesting here, I noticed that -5 often gives better results than -6, in fact, the size is often similar to that of -7 and -8. Fiddling with the settings a bit, I noticed that this is because of the setting "order method: estimate" which seems to produce better results than "2-Level" and sometimes better than "4-Level" as well.

I didn't test on many files, so this might be a coincidence, but on the few files I tested the commandline "flake -8 -m 1" was always faster and always produced bitrates similar or better than "flake -8". Might be worth investigating...

Edit: I just did a short test with the album "Supertramp - Some Things Never Change", comparing the commandlines "-8" and "-8 -m 1".
"-8 -m 1" was of course always way faster, and compressed 8 of the 12 files better than "-8". The differences in bitrate were quite small though, around 0.1-0.2kbps average.


This is really interesting. My tests resulted in not quite as good compression. It could be coincedence. More testing would be great. The order estimate method is a pretty crude 1st attempt at an idea I got from a paper which dealt with speech compression. It suggested a method using the highest order reflection coefficient above a certain threshold. I've found that the method varies widely depending on the type of audio...I imagine it works well for speech, but would need some tweaking for other types of signals. I had once tried to do some testing using gnuplot output, but my statistical analysis skills aren't really advanced enough to know what to look for...so I have left it at a simple threshold for now.

edit: I also want to note that I could almost always pick out the best order or close to it using visual output from gnuplot, but I could never translate that into a mathematical analysis that worked well. There is definitely potential there though.

-Justin

This post has been edited by Justin Ruggles: Oct 18 2006, 02:53
Go to the top of the page
+Quote Post

15 Pages V  « < 9 10 11 12 13 > » 
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: 28th December 2014 - 03:56