Take a look at the CVS repositories here:
http://flac.cvs.sourceforge.net/viewvc/flac/flac/src/share/?pathrev=FLAC_RELEASE_1_2_1__2007_09_17
Harry Griff schreef:
Hi there,
I'm interested in implementing Replay Gain in C++ and believe that
this feature is available in the Flac library.
Op 09-02-12 15:50, Voit, Florian schreef:
Hi everyone,
I'm currently working on project trying to send sensor data from a
microcontroller over radio to another device.
I need compression because the radio has not enough bandwidth to send
it without.
Because the sensor data quiet much
You can just take a look at the FLAC download page:
http://flac.sourceforge.net/download.html
There are links saying FLAC full source code and Nightly CVS tarball.
Op 04-04-12 14:30, Rafael Velasquez schreef:
I have also installe libflac-dev.
so, could you send me the good link please ?
Op 26-04-12 10:27, Ben Allison schreef:
I've seen this before with, e.g. x264, where a bug is repeated in the encoder
and decoder and hence not caught by any tests.
So, would it be useful to include some of tests run by another (or
several other) decoder(s)? Probably an older FLAC release of
I can't read russian, but that part of the website seems pretty
outdated, mentioning FLAC 1.1 as the last news item?
I guess I would like to update the news section with a few items (I
guess that's what makes a website looks 'fresh', I would love to make
FLAC look like an active project :))
On 28-08-12 10:46, Erik de Castro Lopo wrote:
I think thats a great idea. WOuld be happy to have someone pick
this up and run with it.
So I got busy but stumbled upon several things. I'm not sure why there
are two boxes displaying the same news on the homepage right now, so I
made two
Hi all,
I was busy programming a tool to automatically run some tests to update
the FLAC comparison page (http://xiph.org/flac/comparison.html) when I
stumbled across some weird behaviour of the flac program. So I compiled
from git and it seems that this bug still is there. As I don't have any
On 13-12-12 13:20, Max Horn wrote:
On 13.12.2012, at 03:57, Conrad Parker wrote:
IIRC the xiph sites use server-side includes (apache SSI) for headers
and footers. [...]
Yay, yet another version of the website :-).
I am not really a fan of SSI myself, but if this is what is there, and
On 27-12-12 12:30, Max Horn wrote:
1) Status of the flac website repository: As I pointed out, there is a
copy of the website in flac.git, which has diverged from the new
website in flac-website.git. How do you want to proceed with that? For
three alternatives on how to deal with that, and
as it
should. I've updated the sourceforge tracker links, changed all
cvs-links to link to the current git and added some news.
From 49ebeea3e60a0c75c0efccf2f8fba6ed81dc7486 Mon Sep 17 00:00:00 2001
From: Martijn van Beurden martijn@MartijnKubuntu.(none)
Date: Tue, 1 Jan 2013 20:51:58 +0100
Subject: [PATCH
It seems the changelog.html file in the doc/html/-directory in the
flac.git has been used for that purpose, as it mentions a 1.2.2 release
without a release data
On 02-01-13 19:59, Erik de Castro Lopo wrote:
Miroslav Lichvar wrote:
I've received a bugreport that vlc doesn't compile with the
On 07-01-13 00:41, Alex Santos wrote:
It mentions ALAC source code as unavailable and proprietary. The move top
open source occurred on 08/11.
I sent in a patch to fix this yesterday... :)
___
flac-dev mailing list
flac-dev@xiph.org
Hi all,
Lots of bugs and support requests in the sourceforge tracker are related
to the FLAC frontend, which is bundled with FLAC for Windows with the
installer. However, I couldn't find it in git. I really thought the FLAC
frontend was part of the project, but it seems it is some piece of
On 11-01-13 15:26, Miroslav Lichvar wrote:
Very nice. I'd like to see the comparison page updated too. I've just
few questions on the pdf. Was the comparison done on a 32 or 64-bit
system?
All comparisons were done on a 64-bit system. However, I did not see
much deviation from tests in the
On 12-01-13 08:23, pyth.flac-dev.5@spamgourmet.com wrote:
I seem to recall that changes in the second number indicated a minor
change in the *format* of the file itself (for example, 1.1.x to 1.2.x
introduced a new rice coding option used for 24-bit files).
Well, the only change in
On 12-01-13 22:46, Brian Willoughby wrote:
I would suggest that everyone keep in mind the vast installed base of
hardware FLAC recorders and players, and not senselessly make them
obsolete without extremely compelling reasons.
This can be done for the same reason the change from 1.1 to 1.2
Hi all,
Over at the flac users mailinglist a user had some corrupt FLAC files
which showed strange behaviour: decoding of the files failed at the last
few percent for all of them with a few different errors. They were
encoded with flac 1.1.2. I looked into a sample of a corrupt file, I can
On 22-01-13 08:20, Brian Willoughby wrote:
Not even bug fixes?
What bugs? I'm not aware of any bugs. A centralized list of bugs
would be great.
Well, the changelog in the docs directory has been used previously by
Josh to keep track of all changes. It seems the code in cvs had some
bugs
.
On 22-01-13 09:41, Erik de Castro Lopo wrote:
Martijn van Beurden wrote:
Hi all,
Lots of bugs and support requests in the sourceforge tracker are related
to the FLAC frontend, which is bundled with FLAC for Windows with the
installer. However, I couldn't find it in git. I really thought
On 22-01-13 10:02, Erik de Castro Lopo wrote:
If it was never officially part of the FLAC project and FLAC source
code then bugs against it shouldn't be in FLAC's bug tracker :-). Erik
It depends on your definition of 'being officially part of'. This GUI
was developed by a 3rd party but has
On 22-01-13 10:57, Erik de Castro Lopo wrote:
I disagree that it needs to be bundled with FLAC, but agree with it
being desirable. Even if this FLAC GUI is cross platform I don't think
it should be part of the FLAC source code tree.
That certainly makes sense. I think I'll create a new
Hi all,
I've been struggling for several weeks to get Microsoft Visual Studio
2005 to build FLAC. MinGW worked fine, but the resulting binary didn't
support Cyrillic or Greek characters, so I thought MSVC might cut it.
Anyway, I'm not a very good programmer, but I got it working. Probably
Hi guys,
While updating the FLAC website I just found out the Xiph directshow
filters already implement a certain channel mapping. I found this bug:
https://trac.xiph.org/ticket/1657 It seems, from the bug report, that
they use FL, FR, FC, LFE, BL, BR, SL, SR.
On 22-01-13 08:19, Brian
4c65a044616986d3fcc2c00b21d1ad46190f7179 Mon Sep 17 00:00:00 2001
From: Martijn van Beurden mva...@gmail.com
Date: Thu, 24 Jan 2013 22:16:14 +0100
Subject: [PATCH 2/2] Gives the FLAC website a maximum width
Because most text parts get unreadable because of the ever increasing
screen resolutions, it seemed like a good idea to me
Hi all,
I was reading the discussion about this 1.3.0pre1 release on
HydrogenAudio and someone linked an old thread in which one patched FLAC
1.2.1 to support WAV-files larger then 2GB. It might be worth investigating:
http://www.hydrogenaudio.org/forums/?showtopic=84014#entry725304
On 03-03-13 00:22, Erik de Castro Lopo wrote:
I have personally tested this code on:
x86-linux
x86_64-linux
powerpc-linux
Have you tried static building too? I just tried a bunch of switches for
../configure and both --enable-static as well as --disable-shared
On 04-03-13 23:19, Erik de Castro Lopo wrote:
Link please?
http://www.hydrogenaudio.org/forums/index.php?showtopic=99757
Err, thats a link to a post talking about flac's WAV reader being limited
to 4Gig files. Problem is, *all* WAV files greater than 4Gig are mal-formed.
Due to limitations
On 04-03-13 23:36, Erik de Castro Lopo wrote:
However, you should be getting them regardless of whether you are
compiling static or shared.
Yes, I get those for shared as well, but the error that follows it
(error: inlining failed in call to always_inline 'fread' etc.) is only
when
On 06-03-13 09:43, Brian Willoughby wrote:
There is no way for a RIFF/WAVE to exceed 4 GB because all chunks must
be enclosed within a global chunk, which is limited to a 32-bit size.
I agree it's ugly, but if you take a look at the FLAC bug tracker or the
thread on HydrogenAudio that has
On 09-03-13 01:01, Erik de Castro Lopo wrote:
I would like to know how many years I have to wait before we can ditch
this stuff. I intend to do some testing on platforms I have available
today and roll a second pre-release after my testing.
Talking about ditching, there are still .dsp files
Hi all,
Not to be pedantic, but as these were not updated for the pre-releases
(probably because they're not that important or because they were
forgotten?), there are a few things that need to be updated in case of a
release.
- src/libFLAC/format.c has a 'release date' added to the vendor
On 13-03-13 10:49, Marko Uibo wrote:
I plan to test my ~20 GB flac collection how big difference flake -12
gives me. But I still use reference implementation for my main collection.
If I remember correctly gains were less then 0,5%, which for 20GB will
be 100MB, not enough to get even one
Hi all,
I just finished running the scripts I used to write the lossless audio
codec comparison that is on the FLAC website. The results are in the PDF
linked below. As you can see, compression is exactly the same but
decompression is about 15% faster. As expected, all results were lossless.
On 13-03-13 16:05, Cristian Rodríguez wrote:
Cool, just wondering though.. it says The machine used for running
the test has an Intel Core2Duo T9600 with 4GB of RAM and is using
Kubuntu 12.10. .. is the OS in 64 bit mode ? which CFLAGS where used
and what compiler ?
It's 64-bit, I just
On 14-03-13 20:02, Declan Kelly wrote:
The next official release of the FLAC command line should really have
a -9 option for absolute maxed-out big-memory CPU-burning compression.
No. If you want such things, try TAK, OptimFROG, Monkey's Audio or even
LA, you'll lose hardware compatibility
On 14-03-13 21:24, Declan Kelly wrote:
No. I want the tightest possible compression, while remaining 100%
compatible with the subset that all known FLAC decoders can successfully
stream or play now in cars, Hi-Fi units, MP3 players and cell phones.
The out and out most widely supported
On 01-04-13 12:40, Erik de Castro Lopo wrote:
I've tested this on
x86_64-linux
powerpc-linux
i386-openbsd5.2
i386-freebsd9
I've tested this on x86_64-linux as well, but still no static building
possible (see earlier post on this). Someone over at HydrogenAudio has
Hi all,
For testing a few mingw-builds I tried to use ./configure
--disable-thorough-testing (because testing in a virtual machine through
mingw isn't really fast) but it turned out this setting doesn't do
anything.
It turns out these configuration options aren't passed to the test
scripts
On 09-04-13 21:18, Martijn van Beurden wrote:
While going trough test/Makefile, I found this
# This is the full test suite, but only works correctly in-tree.
# In particular test_grabbag.sh, test_flac.sh and test_metaflac.sh
will not
# run correctly out-of-tree.
fullcheck: $(check_SCRIPTS
Hi all,
I was running some tests cross-compiling and natively compiling for
windows with mingw and found something strange: when I try to built flac
statically linked and libogg is available as a dll, flac will use the
dll instead of linking statically. If I built libogg with
On 08-04-13 22:00, Janne Hyvärinen wrote:
On 8.4.2013 21:38, Janne Hyvärinen wrote:
Friendly people on Hydrogenaudio found some bugs with the Unicode
printing code, so I was forced to make adjustments.
[...]
The long line patch is broken and requires much more work, please
ignore it. The
On 15-04-13 17:54, Marcus Johnson wrote:
the audio was also 192,000khz sample rate, forgot to mention that, adn
here are the audio files, the original, the flac, and the decoded from
flac.
the archive is 7zip, Idk where to upload it so I'll just send it to
depositfiles.
As far as I can
That's because FFmpeg is based on flake instead of FLAC. It seems FFmpeg
outperforms FLAC here by quite a large margin, usually the differences
aren't very large at all.
On 15-04-13 18:47, Marcus Johnson wrote:
Also, FFmpeg encodes the audio to only 3/4th the size, that's kinda
strange.
Hi,
I was wondering how much worse FLAC performance would be if it was
compiled integer-only, but while trying to do so (by adding #define
FLAC__INTEGER_ONLY_LIBRARY 1 to config.h, just on x86_64-linux) I got
this error
./include/private/bitmath.h:134:5: error: operator '' has no left
a3b0543a859ebc9c4441d6f20c8cee7f6d361327 Mon Sep 17 00:00:00 2001
From: Martijn van Beurden mva...@gmail.com
Date: Sun, 21 Apr 2013 23:12:16 +0200
Subject: [PATCH] Reduce valgrind num-callers to 50
My Valgrind doesn't run, saying it doesn't support showing more
than 50 entries of a stack trace
---
test
Hi all,
Just as I said I would do in a previous mail to this mailing list
(http://lists.xiph.org/pipermail/flac-dev/2013-January/003644.html),
I've set up a sourceforge project with a remake of FLAC Frontend. After
a few months of development (with loads of help from people at
HydrogenAudio)
Hi,
I was running make fullcheck when I found something weird. After editing
the *expect.meta files , make fullcheck ran all tests and said All
tests passed, but the output included this (this is the last tests from
test_metaflac.sh)
[...]
test case60: --remove --block-type=PICTURE... OK
On 25-04-13 05:30, Erik de Castro Lopo wrote:
The problem is that the failure in the awk script isn't recognised as
a failure in the shell script.
No, really, it's not only that. With the fixed git, I get this when I
change one of the expected values to something else:
[...]
Testing FLAC
On 25-04-13 11:38, Erik de Castro Lopo wrote:
Lets see the patch first and then see if we can make it prettier.
Erik
Sure. Patch attached.
From bae4658ef6f18db9bb8c49fecd01f6eade25554a Mon Sep 17 00:00:00 2001
From: Martijn van Beurden mva...@gmail.com
Date: Thu, 25 Apr 2013 15:20:23 +0200
Sorry, I'm making a big mess of this. Please ignore the previous one. I
used set -x instead of set -e
On 25-04-13 15:25, Martijn van Beurden wrote:
On 25-04-13 11:38, Erik de Castro Lopo wrote:
Lets see the patch first and then see if we can make it prettier.
Erik
Sure. Patch attached
On 28-04-13 13:23, LRN wrote:
On 28.04.2013 13:38, Erik de Castro Lopo wrote:
I have tagged 1.3.0pre4 in git and provided a tarball here:
http://downloads.xiph.org/releases/flac/beta/flac-1.3.0pre4.tar.xz
I have built and tested the git tree on:
linux-x86_64 openbsd5-i386 freebsd5-i386
Hi all,
Sorry for bringing this up this short before the release, but I noticed
something rather strange.
I was doing some more exotic checks on the last pre-release when I tried
test_streams.sh with FLAC 1.3.0 encoding and an older version (1.1.0 or
something like that) decoding. This failed
On 04-05-13 12:41, Erik de Castro Lopo wrote:
Miroslav Lichvar wrote:
On Thu, May 02, 2013 at 09:31:25PM +0200, Martijn van Beurden wrote:
I don't know why this isn't on the changelog, but it is probably still a
good idea to add it. This only breaks compatibility for 24-bit streams.
(So
On 04-05-13 14:17, Martijn van Beurden wrote:
To *1.2.1 - libraries* I would add
- Added support for encoding the residual coding method introduced in
libFLAC 1.2.1 (RESIDUAL_CODING_METHOD_PARTITIONED_RICE2) which will
encode 24-bit files more efficiently
I meant introduced in libFLAC 1.2.0
Yes, those problems are known but weren't easy to fix. It seems they are
ARM-related, as they were present on Raspbian as well. See this mail:
http://lists.xiph.org/pipermail/flac-dev/2013-April/003985.html
Thanks for reporting!
On 24-05-13 15:00, Felix Homann wrote:
Now that I can build FLAC
On 26-05-13 14:20, Martijn van Beurden wrote:
On 26-05-13 11:33, Erik de Castro Lopo wrote:
Hi all,
In my latest commit I have updated all version strings and copyright
dates.
Here are two patches for the website, updating the copyright as well
and copying the changelog. I would like
On 26-05-13 11:33, Erik de Castro Lopo wrote:
[...]
I am now going to do a little testing (and encourage anyone else to do
the same) and hopefully release in the next day or so.
I've ran make fullcheck on
- x86_64-linux-gnu
- arm-linux-gnueabihf (Raspbian)
- i686-pc-mingw32
- MSVC 2012 (tested
On 26-05-13 21:06, Ulrich Klauer wrote:
Your locale probably has the comma as the decimal mark, so
--skip=00:01,11 would work. (Whether it is a good idea to honour
locale settings in command-line arguments is a different matter.)
test_flac.sh is aware of this:
# we use '.' as decimal
On 27-05-13 05:56, Erik de Castro Lopo wrote:
Ulrich Klauer wrote:
I don't think this should be done. The website in flac-website.git and
the one in flac.git/docs/html have diverged and will require some kind
of merge effort.
Actually, I'd prefer stripping down flac.git/docs/html to the bare
On 28-05-13 20:09, Janne Hyvärinen wrote:
On Windows the 32-bit NASM enabled compiles are always fastest. If you
can run 32-bit code on your Linux box you should compile with assembly
optimizations.
That depends on the way you define speed. For decoding this doesn't seem
to be true. I reran
On 05-06-13 00:45, Erik de Castro Lopo wrote:
I notice that in the feeds/feed.xml file there is a item titled Sony
launches its first FLAC-playing receiver but that does not show up on
https://xiph.org/flac/news.html. Any idea what's going on here?
Yeah, sure, I have that all the time. The
anything.
From c35a4b26d6274cf864146f725f8802c55267b3e0 Mon Sep 17 00:00:00 2001
From: Martijn van Beurden mva...@gmail.com
Date: Wed, 5 Jun 2013 19:19:14 +0200
Subject: [PATCH] Change javascript feed fetch from GET to POST
This change should disable caching of the news feed
---
index.html | 2
On 05-06-13 00:27, Erik de Castro Lopo wrote:
Martijn van Beurden wrote:
Considering flac.sourceforge.net, is this ever going to be updated? In
case it should be redirected, I checked on my own sourceforge project
webpage, adding the following two lines to .htaccess should redirect
traffic
On 25-06-13 20:59, Federico Miyara wrote:
What does it mean wasted bits-per-sample in source subblock in the
subbframe header?
Might it be, for instance, that some bits can be discarded at once
because the maximum amplitude is such that renders them constant zero
along the uncoded subblock?
On 26-06-13 07:36, Ralph Giles wrote:
All,
At Erik's request I made flac.sourceforge.net just redirect to
xiph.org/flac/ This will simplify keeping things up to date, since I
never got the sf.net version updating from git.
Thanks!
BTW, I notice the new site has a feed.xml, but no feed.rss.
On 26-06-13 09:06, Erik de Castro Lopo wrote:
If someone has a link to Windows or Mac binaries for the latest
release, please let us know and we will update the download page. We
may even be willing to host the binaries on the Xiph web site. Hope
this clears things up.
There are already
On 01-07-13 16:48, Burak Orçun Özkablan wrote:
[...]
I run your sample codes, encode.c and decode.c, about file encode /
decode. Then, I run
streaming encode / decode with two different source codes but when I
use streaming encode / decode over network in real-time, code throws
LOST_SYNC
is write and read
callback must runs sync. I can not success it, code runs only
reading callbacks and throws LOST_SYNC exception.
2013/7/1 Martijn van Beurden mva...@gmail.com
mailto:mva...@gmail.com
On 01-07-13 16:48, Burak Orçun Özkablan wrote
On 02-07-13 11:01, Burak Orçun Özkablan wrote:
I don't use any metadata when encoding and decoding. When I call
*FLAC__StreamDecoderStateString[FLAC__stream_decoder_get_state(m_decoder)]
*
*
*
it returns
FLAC__STREAM_DECODER_SEARCH_FOR_METADATA
enum value. Is it an error ?
There is always
On 02-07-13 16:13, Burak Orçun Özkablan wrote:
Yes, I have tried plain wav data with file and stream functions of
decoder and encoder. They work succesfully.
Okay, so that's not the problem. Clear.
You're right about FLAC can't find the first block in stream, because
I didn't add any
On 16-07-13 12:32, Leigh Dyer wrote:
The first time I tried, the resulting file encoded just fine, but after
trying a few more times, cutting at slightly different points, I was
able to get a snippet of that section that exhibits the problem. This is
short enough that I think I can link to it
On 19-08-13 17:55, lvqcl wrote:
I think that moving from VS2005 to VS2010 or 2012 is a good isea,
but... for example, Winamp team still uses Visual Studio 2008 to build
Winamp and all necessary libraries including libFLAC.dll.
Yes, sadly, because of the rather large differences between MSVC
On 17-09-13 10:34, Erik de Castro Lopo wrote:
There is something really weird around line 2012 of the patch file.
Can you try again please?
I think that's because I corrected a small mistake in the patch file
after it was created, I should have known there are hashes to check stuff.
This
? Anyway, here are two patches that should 'fix' this.
From 8e947fc92078915e04d252d1b2aa2b028f53cf63 Mon Sep 17 00:00:00 2001
From: Martijn van Beurden mva...@gmail.com
Date: Wed, 18 Sep 2013 18:51:17 +0200
Subject: [PATCH] Fix documentation rice partition order
For some reason all documentation
On 22-09-13 10:31, lvqcl wrote:
I measured encoding speed of 24-bit WAV files. It turns out that 32-bit
encoder made by GCC is ~1.7x times slower than 32-bit encoder made by MSVS.
Strange, I'm not able to reproduce your findings. I did found something
rather odd though. I thought MSVC, ICL
-comparison.patch
Sorry for the inconvenience. I really should get to know git branching
and rebasing and stuff like that.
On 30-09-13 22:06, Martijn van Beurden wrote:
Once more big patches, this time updating the comparison and links pages.
http://www.icer.nl/misc_stuff/0001-Add-more-brands-to-links
Hi all,
I had some time to spare so I made a comparison of current git versus
the FLAC 1.3.0 release considering encoding and decoding speed. This was
done with GCC 4.7.3 for AMD64 linux.
There's a very nice speedup visible. Keep up the good work!
FLAC 1.3.0 versus git a6a4b6f.pdf
Hi all,
It seems my e-mail is caught by the spam filter. Once again, a few
patches for the FLAC website, this time linked instead of attached.
http://www.icer.nl/misc_stuff/FLAC-website-news-updates.zip
On 02-01-14 16:09, Martijn van Beurden wrote:
Hi,
Once more a few patches for the FLAC
I don't understand what it is you don't get about those blocksizes. For
subset streams, the blocksize has to be one of 576/1152/2304/4608 or
256/512/1024/2048/4096 if the samplerate is lower then or equal to
48kHz, if higher, 8192 and 16384 are allowed too. If you use any other
blocksize, the
On 19-01-14 09:43, Барт Гопник wrote:
If answer on any of these questions is yes, documentation on the
website should be updated (fixed)!
No one here knows for sure, as Josh won't probably be listening
to answer these questions, so I guess most of us are actually
relying on the documentation
is a patch to fix this.
From c78f9d13087fbaf435cea3b380a929466c5860c7 Mon Sep 17 00:00:00 2001
From: Martijn van Beurden mva...@gmail.com
Date: Mon, 3 Mar 2014 14:17:56 +0100
Subject: [PATCH] Repairs test_grabbag.sh
The change from /bin/sh to /bin/bash -e (commit 1d3d50) broke
the cuesheet tests
op 11-03-14 15:57, Olivier Tristan schreef:
I may say something stupid but is this helpful ?
http://stackoverflow.com/questions/6121792/how-to-check-if-a-cpu-supports-the-sse3-instruction-set
That question on stackoverflow is about CPU support, the patch
you replied to was about OS
op 15-03-14 06:15, lvqcl schreef:
I hope that this code will help to avoid bug reports such as
http://sourceforge.net/p/flac/bugs/409/
It's even mentioned in the FAQ, so it's really nog a bug, not
even a bug :)
http://xiph.org/flac/faq.html#tools__different_sizes
AFAIK standard FLAC already reaches suchs speeds when used with
the -0 option when used on more than one core (i.e. more than
one WAV stream at a time). For some performance figures, take a
look at http://xiph.org/flac/comparison.html
op 16-03-14 18:27, Nouvelle Collection schreef:
Hello,
op 22-03-14 09:17, lvqcl schreef:
I added XIPH_ADD_CFLAGS([-mfpmath=387]) into configure.ac
Still the result is different from SSE version.
Maybe it should be left alone. The difference is not really
harmful (aside from the people wondering who might think it is a
serious bug), it has been
op 25-03-14 10:01, Nouvelle Collection schreef:
What is nowadays lossless compression's limit (tested on a
large library of music samples, because of course, it depends
on the music we do the tests on)
I did the comparison that's on xiph.org/flac/comparison.html. I
can assure you, that's
That's odd. I just tried, but I'm not having any trouble
building FLAC on MSVC 2005. Could it be stdint.h is provided by
a platform SDK?
In that case, this doesn't really break compatibility, I
remember a platform SDK was necessary to build FLAC with MSVC
2005 anyway.
op 03-05-14 19:46,
op 27-05-14 16:04, Uli Franke schreef:
Is there a way to output small blocks/chunks/ogg pages instead
run-length encoding such silent passages into a single page?
The official FLAC encoder has an option
--disable-constant-subframes, which does exactly that.
As far as I know, R128 as ReplayGain isn't really considered
final yet (see
http://wiki.hydrogenaud.io/index.php?title=ReplayGain_2.0_specification
for example), so it would probably be a bit early to update this
in the FLAC source.
op 16-06-14 10:15, Olav Sunde schreef:
I mention metaflac
op 18-06-14 16:54, Барт Гопник schreef:
Please help me understand what values of FFMPEG's compression_level
preset generate subset FLAC stream and what not-subset?
Levels 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 and 10 should generate
subset-compatible streams, 11 and 12 should not. The difference
is
op 19-06-14 11:20, Барт Гопник schreef:
That's all parameters that I need to check?
That is correct. See http://xiph.org/flac/format.html, it says
The Subset makes the following limitations on what may be used
in the stream:
- The blocksize bits in the frame header must be 0001-1110.
The
op 19-06-14 02:00, Erik de Castro Lopo schreef:
Hi all,
[...]
Anything else I've forgotten or people would like to see?
Like I reported just before the release of 1.3.0 (mail of Fri,
05 Apr 2013 08:25:10 +0200, to be specific), compiling on
Raspbian (Debian Wheezy, GCC 4.6) returns quite
op 19-06-14 19:31, lvqcl schreef:
flac-website Git is also slightly outdated (dead links, some text
is obsolete, etc). Maybe it's time to update it too?
Yeah, I might do that sometime soon.
And, doc/html/* in flac Git is even older.
I've cleaned that up quite recently:
op 19-06-14 20:17, lvqcl schreef:
It seems quite common for 16-bit files:
I second that. Apparently it depends on the kind of music, some
albums have no warnings (mostly classical music it seems), some
have over 20 per file. I've seen a few with 100 per file
(things like rock and heavy
op 19-06-14 21:16, lvqcl schreef:
2) documentation_bugs.html
The following are major known bugs in the current (1.2.1) release:
1.2.1 is not the current release. And IIRC the first issue (--replay-gain but
no --padding/-P)
was fixed shortly after the 1.2.1 release.
Okay, I just checked
op 27-06-14 14:11, Erik de Castro Lopo schreef:
There has been at least one person on this list who is able to do
perfromance tests on FLAC. I would appreciate it if someone could
run such a performance test before and after the above commit.
Are you specifically referring to the ARM platform
op 28-06-14 00:23, Erik de Castro Lopo schreef:
Martijn van Beurden wrote:
Are you specifically referring to the ARM platform or to any
platform?
The main CPU architectures; x86_64 and ix86
Erik
Okay, I ran the usual scripts, and the results can be found
here:
http://www.audiograaf.nl
op 28-06-14 07:56, Martijn van Beurden schreef:
Okay, I ran the usual scripts, and the results can be found
here:
http://www.audiograaf.nl/misc_stuff/long-set-of-samples-check-commit-40e817.pdf
As far as I can see, this is within measurement error.
I forgot to mention: this script was ran
op 02-07-14 17:35, Барт Гопник schreef:
Anybody read it?
As far as I know, there is no list that keeps track of devices
that only play subset files. That's because there are quite a
few ways to be non-subset. My portable audio player starts to
stutter mildly when files have LPC blocks with a
Hi all,
I thought it was a good idea to get an overview of the
developments since the release of 1.3.0, so here are a few graphs.
The first was compiled with GCC 4.8, the second was compiled
with MSVC 2013. Both were tested on a Kubuntu 14.04 machine,
with an Intel Core 2 Duo T9600 (SSE
1 - 100 of 244 matches
Mail list logo
