Skip to main content

Topic: New FLAC encoder (Read 288794 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • krmathis
  • [*][*][*][*][*]
New FLAC encoder
Reply #200

The problem seems to be line #277 in flake-enc/libflake/md5.c
Cause if I change "bswap_16" to "flake_bswap_16" the error message change according to it.

Fixed.  I forgot to #include "bswap.h" at the top of md5.c.

-Justin

Success!
There is still something wrong, cause the compression rate really sucks.
Flake: "ratio: 0.973 | bitrate: 1372.5 kbps | bytes: 40801624 "
FLAC 1.1.2: "22381217 bytes, ratio=0.534"

Same big/little-endian problem as we had earlier maybe?


Edit: Saw you reply after posting this one.
1. Using revision 67
2. The resulting FLAC file is just noice.
  • Last Edit: 25 September, 2006, 03:16:23 PM by krmathis

New FLAC encoder
Reply #201
Same big/little-endian problem as we had earlier maybe?

Edit: Saw you reply after posting this one.
1. Using revision 67
2. The resulting FLAC file is just noice.

Yes indeed.  It should be fixed now in r69.

  • krmathis
  • [*][*][*][*][*]
New FLAC encoder
Reply #202

Same big/little-endian problem as we had earlier maybe?

Edit: Saw you reply after posting this one.
1. Using revision 67
2. The resulting FLAC file is just noice.

Yes indeed.  It should be fixed now in r69.

Sadly it is not.
Revision 69 still output garbled data at a compression ratio of 0.973 (I removed all source traces and pulled a fresh one).

Thanks a lot!

New FLAC encoder
Reply #203


Same big/little-endian problem as we had earlier maybe?

Edit: Saw you reply after posting this one.
1. Using revision 67
2. The resulting FLAC file is just noice.

Yes indeed.  It should be fixed now in r69.

Sadly it is not.
Revision 69 still output garbled data at a compression ratio of 0.973 (I removed all source traces and pulled a fresh one).

Thanks a lot!

Very odd.  I can't figure it out.  Try hand-editing config.h and remove the line with #define WORDS_BIGENDIAN 1.  And/or put a printf line right before the call to bswap_16 in wav.c.  Those won't fix anything, but might rule out some things.

[edit]changed the instructions slightly

[edit2] btw...i should have sourceforge compile farm access in the next 24-hrs. that way i can test on other platforms.
  • Last Edit: 25 September, 2006, 07:28:22 PM by Justin Ruggles

New FLAC encoder
Reply #204
As usual the fix was too simple for me to notice right away...just a spelling error.  *sigh*  I have fixed the problem and tested on a ppc (yay for compile farm).  Thanks for finding the problem so that I could fix it.

-Justin

  • krmathis
  • [*][*][*][*][*]
New FLAC encoder
Reply #205
As usual the fix was too simple for me to notice right away...just a spelling error.  *sigh*
You certainly nailed it!

Flake rev69: ratio: 0.973 | bitrate: 1372.5 kbps | bytes: 40801624
Flake rev77: ratio: 0.527 | bitrate: 743.6 kbps | bytes: 22107579
FLAC 1.1.2: 22381217 bytes, ratio=0.534

Quote
Thanks for finding the problem so that I could fix it.
No problem!
..and thank you for fixing the bugs I have found.

** now on to testing this "beast" **

  • plinej
  • [*]
New FLAC encoder
Reply #206
I just found this thread today and have skimmed thru it. I was happy to see that flac is being put into ffmpeg. I just compiled the latest ffmpeg source from svn to test this out. It seemed to encode fine but playing back the file with xmms does not display the length of the track and will not let you skip ahead. My flac and flake encoded files work fine in xmms though. I just wanted to see if that was a known problem or maybe I encoded wrong. I just used the example posted in this thread:

ffmpeg -i test.wav test.flac

  • xmixahlx
  • [*][*][*][*][*]
New FLAC encoder
Reply #207
i packaged a svn snapshot for debian

available at the usual place


later

  • Mangix
  • [*][*][*][*][*]
New FLAC encoder
Reply #208
i got a question about the code being used in flake. when i tried to compile flake with Microsoft Visual C++, i noticed that flake uses data types such as int32_7 and uint63_t. i also read on the wikipedia about inttypes.h and found out that they have equivalents which are built in the C++ language itself.

so my question is, are there any main diffrences between, let's say, "int32_t" and "long"?

edit: reason that i'm asking is because the Platform SDK does not give an inttypes.h file.
  • Last Edit: 02 October, 2006, 01:23:05 AM by Mangix

New FLAC encoder
Reply #209
i got a question about the code being used in flake. when i tried to compile flake with Microsoft Visual C++, i noticed that flake uses data types such as int32_7 and uint63_t. i also read on the wikipedia about inttypes.h and found out that they have equivalents which are built in the C++ language itself.

so my question is, are there any main diffrences between, let's say, "int32_t" and "long"?

edit: reason that i'm asking is because the Platform SDK does not give an inttypes.h file.

The main difference has to do with 64-bit platforms.  Rather than explain it, maybe a snippet from glibc's stdint.h (which is included by inttypes.h) would help.  inttypes.h is part of the ISO C99 standard, which is the baseline standard used in Flake.

Code: [Select]
#ifndef __int8_t_defined
# define __int8_t_defined
typedef signed char        int8_t;
typedef short int        int16_t;
typedef int            int32_t;
# if __WORDSIZE == 64
typedef long int        int64_t;
# else
__extension__
typedef long long int        int64_t;
# endif
#endif

/* Unsigned.  */
typedef unsigned char        uint8_t;
typedef unsigned short int    uint16_t;
#ifndef __uint32_t_defined
typedef unsigned int        uint32_t;
# define __uint32_t_defined
#endif
#if __WORDSIZE == 64
typedef unsigned long int    uint64_t;
#else
__extension__
typedef unsigned long long int    uint64_t;
#endif


For MSVC, you can try adding this bit of code somewhere.  I will add it myself in the near future...I've been meaning to, but just keep putting it off.
Code: [Select]
#if defined(_WIN32) && defined(_MSC_VER)
typedef __int8 int8_t;
typedef unsigned __int8 uint8_t;
typedef __int16 int16_t;
typedef unsigned __int16 uint16_t;
typedef __int32 int32_t;
typedef unsigned __int32 uint32_t;
typedef __int64 int64_t;
typedef unsigned __int64 uint64_t;
#endif


If you need me to explain more I can.
-Justin

edit: added the msvc stuff
  • Last Edit: 02 October, 2006, 02:20:21 AM by Justin Ruggles

  • Mangix
  • [*][*][*][*][*]
New FLAC encoder
Reply #210
from looking at the code, i can only guess that on 32-bit platforms, int64_t and uint64_t must be defined diffrently in order to work.

also thanks for that piece of code that you put there. helps a lot. i'm don't have much experiance in c++ so that code helps.

  • wisodev
  • [*][*][*]
  • Developer
New FLAC encoder
Reply #211
I have builded latest Flake (Win32) from SVN revision 95:

Download from my Website

or use direct links:

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

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

wisodev

  • MedO
  • [*][*][*][*]
New FLAC encoder
Reply #212
Thanks wisodev!
What are the general changes from r48?

  • wisodev
  • [*][*][*]
  • Developer
New FLAC encoder
Reply #213
What are the general changes from r48?


Well Flake is in constant development so I decided to build fresh binary from latest SVN sources. General changes (in current SVN version) are listed in Flake Changelog file included in src archive.

  • Mangix
  • [*][*][*][*][*]
New FLAC encoder
Reply #214
wisodev: which compiler do you use? MinGW?

  • MedO
  • [*][*][*][*]
New FLAC encoder
Reply #215
wisodev: which compiler do you use? MinGW?


Quote
I am using Intel C++ compile at version 8.0.40 and C99 switch (this is req.)


But Flake compiles fine with MinGW. I just tried it and, after getting gcc 4.1 to run, it's just as fast as wisodev's build for me.

  • Mangix
  • [*][*][*][*][*]
New FLAC encoder
Reply #216
i tried out one of wisodev's builds and his seem to be a few seconds faster at mode -12 for me. the other executable that i tested was one compiled by me.

  • MedO
  • [*][*][*][*]
New FLAC encoder
Reply #217
i tried out one of wisodev's builds and his seem to be a few seconds faster at mode -12 for me. the other executable that i tested was one compiled by me.


Here's my build:
Flake r100 mingw-build

Only the "naked" binary, though.

Compiler Flags: -s -O3 -fexpensive-optimizations -march=i686
Compiler Version: gcc 4.1.1
  • Last Edit: 03 October, 2006, 05:00:50 AM by MedO

  • Mangix
  • [*][*][*][*][*]
New FLAC encoder
Reply #218
bah. now i can't get rev95 to work. it keeps saying "error parsing filenames" when i try to encode it.

"flake -12 C:\test\spirit.wav C:\test\spirit.flac" is the command line that i use.

edit: interesting. now i don't need to even specify an output file. pretty interesting...
  • Last Edit: 02 October, 2006, 07:55:26 PM by Mangix

New FLAC encoder
Reply #219
But Flake compiles fine with MinGW. I just tried it and, after getting gcc 4.1 to run, it's just as fast as wisodev's build for me.

I have not done any gcc4 testing, much less under MinGW.  Were there any compile issues that I may need to solve or did everything build smoothly?  Since the build system is hand-made, not autotools, I've been trying to put it through more tests.

Thanks,
Justin

  • Mangix
  • [*][*][*][*][*]
New FLAC encoder
Reply #220
i just did a short test with 3 encoders. the first was my own compiled one, the second was MedO's one, and the third was wisodev's compiler.

the results sucked because my compile took the longest to encode while MedO's compile took 61 seconds and wisodev's took 64 seconds. mine took 65.

New FLAC encoder
Reply #221
bah. now i can't get rev95 to work. it keeps saying "error parsing filenames" when i try to encode it.

"flake -12 C:\test\spirit.wav C:\test\spirit.flac" is the command line that i use.

edit: interesting. now i don't need to even specify an output file. pretty interesting...

Correct.  Now you don't have to specify the output if you want the same base name, but if you want a specific output file, you have to now use "-o output.flac".  The order method switch was changed to "-m".  I'm working on a new option system right now though, so things may change again before the next full release. I hope to add multiple file input as well.  Everything will be documented better for the release...the current svn version is undergoing pretty constant changes.

edit: typo
edit2: another typo...
  • Last Edit: 02 October, 2006, 08:27:27 PM by Justin Ruggles

  • Mangix
  • [*][*][*][*][*]
New FLAC encoder
Reply #222
heh. i just tried out rev95 again with foobar2000's Converter and the thing blew up on me. the command line that i used was "-12 - -o %d" and when i tried it, when it finished the first or second tracked, foobar2000 gave an error saying "Error flushing file". and also, the output file was "filename.flac=". i am not even sure why there was an = at the end.

edit: why the hell do i always mix up line with like...
  • Last Edit: 02 October, 2006, 09:46:52 PM by Mangix

New FLAC encoder
Reply #223
heh. i just tried out rev95 again with foobar2000's Converter and the thing blew up on me. the command line that i used was "-12 - -o %d" and when i tried it, when it finished the first or second tracked, foobar2000 gave an error saying "Error flushing file". and also, the output file was "filename.flac=". i am not even sure why there was an = at the end.

edit: why the hell do i always mix up line with like...

I think it was a bug in my code.  Try rev96.

edit: a little explaining.  I had forgotten that you have to include the trailing '\0' in the character count for strncpy.
  • Last Edit: 02 October, 2006, 10:55:58 PM by Justin Ruggles

  • Mangix
  • [*][*][*][*][*]
New FLAC encoder
Reply #224
yep. looks like it's fixed. thank you