Re: [flac-dev] FLAC 1.3.2 has been released
On Sun, Jan 01, 2017 at 01:23:20PM +1100, mle...@mega-nerd.com wrote: > > The latest version of FLAC has been releases. See: > > https://xiph.org/flac/index.html The official website doesn't link to the SourceForge project, which seems to be the only place that's hosting the 1.3.2 files. As long as the xiph.org download site is still out of date, the official website shouldn't be pointing to it. > The source tarball is also available at: > https://sourceforge.net/projects/flac/files/flac-src/ > > and similarly the Windows binaries at: > https://sourceforge.net/projects/flac/files/flac-win/ -- -Dec. --- "Mosaic is going to be on every computer in the world." - Marc Andreessen, 1994 ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] FLAC 1.3.2 has been released
On Sun, Jan 01, 2017 at 01:46:20PM +1100, mle...@mega-nerd.com wrote: > > The Xiph.org download directory and github.com/xiph/flac don't seem to have > been updated automatically as I expected. I'm chasing that. The download host is hosted by Oregon State University - is it a mirror site that's just for Xiph projects? -- -Dec. --- "Mosaic is going to be on every computer in the world." - Marc Andreessen, 1994 ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] FLAC 1.3.2 has been released
On Sun, Jan 01, 2017 at 01:46:20PM +1100, mle...@mega-nerd.com wrote: > > The Xiph.org download directory and github.com/xiph/flac don't seem to have > been updated automatically as I expected. I'm chasing that. I should have checked that the new downloads were available from the official site, before announcing. 20 minutes after making the announcement, someone was asking how to use the new release with the EAC frontend. I'm going to reply saying to just drop in the new flac.exe. -- -Dec. --- "Mosaic is going to be on every computer in the world." - Marc Andreessen, 1994 ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] FLAC 1.3.2 has been released
On Sun, Jan 01, 2017 at 01:23:20PM +1100, mle...@mega-nerd.com wrote: > Please feel free to spread the word and please reply to this > email to let us know where this is being announced. Announcement was made on Facebook: https://www.facebook.com/flac.audio/posts/10154824982999519 -- -Dec. --- "Mosaic is going to be on every computer in the world." - Marc Andreessen, 1994 ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] FLAC 1.3.2 has been released
On Sun, Jan 01, 2017 at 07:40:57PM +, maurit...@xs4all.nl wrote: > > FLAC 1.2.1 is the last version that works on Win95/98/NT4/2000 and > > also it still has in_flac.dll (a plugin for Winamp 2.x). Also 1.2.1 > > is the latest official binaries that don't require SSE2. So it can > > be useful for some (very small) group of people. > > Considering a newer version is posted right above 1.2.1 version I assume most > traffic is from direct links from a third party to the SourceForge binary. > Otherwise most people would be opting for the newer one. My guess is that the > majority of people downloading 1.2.1 from SF.net don’t even know there is a > newer version and keep using an unsafe version. Is there a way to get the Referer logs from SourceForge? > My suggestion would be to keep older versions on the Xiph download site and > remove all binaries from SourceForge (perhaps only keep 1.3.2 there). People > who specifically need to find older versions can still get it from Xiph while > people being sent to the outdated 1.2.1 version from a third party site will > need to Google for it and will most likely stumble upon the relevant Xiph > page and get the most recent version. -- -Dec. --- ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Facebook page for FLAC
On Tue, Dec 27, 2016 at 04:13:28PM +, oresteszoupa...@hotmail.com wrote: > > That's great! I reckon when the release happens someone should also make a > Hacker News post and maybe also certain sub-reddits would like to know about > it. This might be overkill, but we could also set up a Facebook Event for the next release. It would be of absolutely no benefit to FLAC, but it might help to spread the word a bit further. We would need to have some advance notice. The post on HydrogenAudio has pre1 in the subject line; there isn't any need to 'bump' that to pre3, but a separate thread for the actual release would stand out better for regular forum users and for Web searches. If any Bandcamp developers are on this list, can we get a blog post or other announcement (through the many channels that Bandcamp has built up over the years to artists and fans)? -- -Dec. --- "Mosaic is going to be on every computer in the world." - Marc Andreessen, 1994 ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] Facebook page for FLAC
I'm one of the co-admins of the Facebook page for FLAC. 15 hours ago, I posted a message giving a vague "heads up" that a new release is on the way. Since then there have been 3 shares, 6 comments, 128 likes and 4451 people reached. That's slightly more than the page's audience. That's more than what the previous release announcement (from November 2014) got. -- -Dec. --- ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] 1.3.2pre3 (Hopefully final)
On Thu, Dec 22, 2016 at 12:19:21AM +, oresteszoupa...@hotmail.com wrote: > > For what it's worth, I tested both the 32- and 64-bit flac.exe's on my > Windows 10, with about 45 WAV files I have. > > Got some warnings about unexpected metadata, but the audio was encoded > fine. Using the --keep-foreign-metadata flag cleared those warnings. Excellent! Do you have any of the popular front-end software that rips from CD and then performs the encoding in parallel? Do we have any front-end developers on this list? Most of them use a DOS window for the encoder (flac.exe or LAME for mp3) instead of using libFLAC (or the mp3 equivalent). I would be concerned that at least one of these might not work with the latest flac.exe . > On 21/12/2016 21:55, Erik de Castro Lopo wrote: > > Hi all, > > > > New pre-release here is at: > > > > http://mega-nerd.com/tmp/flac-1.3.2pre3-win.zip > > http://mega-nerd.com/tmp/flac-1.3.2pre3.tar.xz > > > > > > Really need someone to test the Windows binaries because I don't have > > Windows. -- -Dec. --- ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] FLAC implementation in Windows 10
On Sat, Jul 18, 2015 at 03:16:56PM -0700, bri...@audiobanshee.com wrote: > There might even be a good reason for Microsoft to use the lowest compression > level: it probably takes less CPU to compress and decompress, compared to the > maximum compression ratios. There might be a CPU "sweet spot" for Bandcamp, in terms of overall server costs. Every FLAC that I have ever downloaded from Bandcamp (whether free or paid, high-def or Red Book Stereo) has not been compressed with the maximum level. I wrote a shell script to repack FLAC files at the maximum compression level, optionally with comments saved to a separate text file (if they contain lyrics or extensive notes). -- -Dec. --- (no microsoft products were used to create this message) ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] FLAC implementation in Windows 10
On Mon, Jul 13, 2015 at 01:28:22PM +0200, mva...@gmail.com wrote: > > FLAC is not the only one though, Apple Lossless has been added > to the mix in the same way, but (properly) creates smaller files. Can anyone on the list (possibly someone who works for MSFT) get this fixed before Win10 is released? -- -Dec. --- "Mosaic is going to be on every computer in the world." - Marc Andreessen, 1994 ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Strange things happening at SourceForge
On Thu, May 28, 2015 at 12:43:32PM +0100, maurit...@xs4all.nl wrote: > I meant who is registered as project owner, not neccesarily who started it. > You are listed as ‘flac-maitainer’ (sic) so I assume it will be alright when > SourceForge needs to contact someone. We shouldn't assume that SF.net will bother to contact anyone, if they are INSTALLING ADWARE on abandoned projects with nobody's consent. We should be more proactive in defending against this. -- -Dec. --- (no microsoft products were used to create this message) ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [PATCH] Improve LPC order guess
On Mon, Dec 08, 2014 at 12:13:13PM -0800, mle...@mega-nerd.com wrote: > > Martijn van Beurden wrote: > > > Sorry, most of the testmaterial isn't copylefted, and I don't > > think it is possible to get a nice copylefted test library. > > I don't think we need it to be copy left. We would keep it as > a separate git repo of test files, and we could probably just > use snippets instead of whole peices and claim fair use: > > https://en.wikipedia.org/wiki/Fair_use > > Maybe we shoud collect some samples. There are probably some copyright owners who would be delighted to have their (original, copylefted) works included for the betterment of FLAC. Bandcamp (who make heavy use of FLAC on their servers) might know some of them, if anyone from Bandcamp is on the list. -- -Dec. --- "Mosaic is going to be on every computer in the world." - Marc Andreessen, 1994 ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] [SECURITY] [DSA 3082-1] flac security update
For anyone not on the Debian mailing list, the distribution has patched FLAC against the vulnerability, with older versions. The Ubuntu distribution has done something similar. - Forwarded message from Sebastien Delafond - Subject: [SECURITY] [DSA 3082-1] flac security update Date: Sun, 30 Nov 2014 14:36:27 +0100 From: Sebastien Delafond To: debian-security-annou...@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 - - Debian Security Advisory DSA-3082-1 secur...@debian.org http://www.debian.org/security/Sebastien Delafond November 30, 2014 http://www.debian.org/security/faq - - Package: flac CVE ID : CVE-2014-8962 CVE-2014-9028 Debian Bug : 770918 Michele Spagnuolo, of Google Security Team, and Miroslav Lichvar, of Red Hat, discovered two issues in flac, a library handling Free Lossless Audio Codec media: by providing a specially crafted FLAC file, an attacker could execute arbitrary code. For the stable distribution (wheezy), these problems have been fixed in version 1.2.1-6+deb7u1. For the testing distribution (jessie) and unstable distribution (sid), these problems have been fixed in version 1.3.0-3. We recommend that you upgrade your flac packages. Further information about Debian Security Advisories, how to apply these updates to your system and frequently asked questions can be found at: https://www.debian.org/security/ Mailing list: debian-security-annou...@lists.debian.org -- - End forwarded message - -- -Dec. --- (no microsoft products were used to create this message) ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] FLAC version 1.3.1 has been released
On Wed, Nov 26, 2014 at 07:52:02PM -0800, mle...@mega-nerd.com wrote: > > Version 1.3.1 of FLAC has been released and is available from the > download directory here: > > http://downloads.xiph.org/releases/flac/ There is nothing on the News page about the new release. https://www.xiph.org/flac/news.html Also, the home page depends on JavaScript to pull in the News panes. https://www.xiph.org/flac/ A browser with JS disabled will see a message instead: It seems you've disables Javascript. This news feed requires it. Sorry This appears twice, with the same typo on 'disables'. -- -Dec. --- (no microsoft products were used to create this message) ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Two new CVEs against FLAC
On Tue, Nov 25, 2014 at 12:29:33AM -0800, mle...@mega-nerd.com wrote: > > CVE-2014-9028 : Heap buffer write overflow > CVE-2014-8962 : Heap buffer read overflow Is it known what other FLAC decoding software or firmware is vulnerable to these overflows? Any software player that was derived from the official FLAC codebase probably is, and most active 3rd party developers will probably get a new release out soon anyway, even if their code was not vulnerable. Embedded systems with native FLAC playback, such as DVD players and portable devices, may never get updated. -- -Dec. --- (no microsoft products were used to create this message) "Mosaic is going to be on every computer in the world." - Marc Andreessen, 1994 ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] New release
On Tue, Nov 25, 2014 at 12:44:10AM +0300, lvqcl.m...@gmail.com wrote: > > > Is anyone from the Rockbox project on this list? > > IIRC Rockbox uses ffmpeg decoder. It does! http://www.rockbox.org/wiki/SoundCodecs -- -Dec. --- (no microsoft products were used to create this message) "Mosaic is going to be on every computer in the world." - Marc Andreessen, 1994 ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] New release
On Sun, Nov 23, 2014 at 03:19:53PM +, maurit...@xs4all.nl wrote: > >> Considering Windows binaries: in case no new binaries are provided, please > >> at least remove the old ones from sourceforge. As can be gleaned from some > >> bug reports, support requests etc. on sourceforge, people are still > >> happily downloading old versions. > > > > Agreed. Particularly if there is a CVE issue it makes sense to stop > > suggesting 1.2.1 is the most recent version at all the places we have some > > control over. I posted a "heads up" to the Facebook page just now. No mention of a CVE, just that there is a new release coming this week. https://www.facebook.com/flac.audio It has the official website listed as https://xiph.org/flac Is anyone from the Rockbox project on this list? If the CVE issue affects playback (on architectures that can run Rockbox) then a new Rockbox release should have the new FLAC code. -- -Dec. --- (no microsoft products were used to create this message) ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Disk fragmentation
On Tue, Sep 23, 2014 at 06:42:16PM +0300, c...@sci.fi wrote: > I don't know how big issue this is in *nix environments but added > buffering would definitely be a nice change for the Windows frontend. It depends on the file system being used. With almost every Linux distro, you can choose which FS to use at install time. Most of them have solved most of the problems of fragmentation, at the OS level. Whereas NTFS seems to actually make the problem worse, by allocating blocks in ways that make fragmentation a bigger problem. What I have done for testing that involves lots of files, is create a partition just for the test files, and reformat it each time. If it's small enough, it could be formatted as FAT for added speed. -- -Dec. --- (no microsoft products were used to create this message) "Mosaic is going to be on every computer in the world." - Marc Andreessen, 1994 ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Retuning compression levels
On Mon, Sep 22, 2014 at 06:39:43PM +1000, mle...@mega-nerd.com wrote: > Martijn van Beurden wrote: > > > I dropped -e because > > it's compression improvement isn't worth the slowdown, but it is > > easy for the user to add this anyway. > > I think we should keep -e but may print a warning. The reason to keep it > is so that we do not break some random flac frontend that has this as > an option. I think what Martijn meant was that -e is no longer part of the numbered preset levels, not that the -e option is being deprecated. Any deprecated options should of course print a warning instead of causing an error, because of so many frontends and home-brew scripts that could be still passing them to the command line. -- -Dec. --- (no microsoft products were used to create this message) "Mosaic is going to be on every computer in the world." - Marc Andreessen, 1994 ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] patch for win_utf8_io.c: vsnprintf_s vs. MinGW
On Thu, Sep 18, 2014 at 10:08:29PM +1000, mle...@mega-nerd.com wrote: > > Does FLAC still support all the Windows and Mac and *nix GUI frontends? > > I mostly use abcde, on the command line. > > You don't understand, the frontends support FLAC, not the other way round > :-). I was using the userland definition of "support", where it's a 2-way thing. Minor changes in how the command-line encoder writes to stdout could be enough to break the frontends that use FLAC.EXE instead of the library, for example. That should be the frontend developer's problem, but the end user will only see "FLAC not working", and they will complain loudly about it on their chosen Web forum. -- -Dec. --- (no microsoft products were used to create this message) ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] patch for win_utf8_io.c: vsnprintf_s vs. MinGW
On Thu, Sep 18, 2014 at 07:53:12PM +1000, mle...@mega-nerd.com wrote: > I thought Micorsoft had recently stopped supporting WinXP. Apparently they changed their mind, due to a large number of users not upgrading. Security updates, including a monthly malware detection tool, are still released for XP on Windows Update. > If Micorsoft has stopped supporting it I see no reason for FLAC to support it. I know a lot of people who still use XP, despite me telling them that Ubuntu is a better option for their PC. Does FLAC still support all the Windows and Mac and *nix GUI frontends? I mostly use abcde, on the command line. -- -Dec. --- (no microsoft products were used to create this message) ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] Supporting real-time UTC timestamp data
Interesting article: "Time-coding audio files" http://www.windytan.com/2014/06/time-coding-audio-files.html The author is a signals hacker who has spoken at CCC and other events, and has determined that "There's no standard method for doing this with WAV or FLAC files". Where "this" means recording the UTC time-of-day in the audio stream, as ongoing data, as opposed to knowing the start time and elapsed time. When recording radio stations (for logging purposes) or environmental noise (which may include long periods of silence that don't get logged) and telephone call speech (for "training purposes") it is often more practical to have a constant timecode at playback that corresponds to the "wall clock" UTC at time of recording. The article proposes 2 methods (with working Perl code) to embed the time as in-band noise in the audio. One method (LSB stealing) requires lossless encoding; the other is audible but can survive lossy encoding. I'm sure that BWF supports timecode (SMPTE or compatible) as out-of-band data, and I assumed that FLAC also had some support for this. Was I wrong? -- -Dec. --- (no microsoft products were used to create this message) ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] flac-dev Digest, Vol 100, Issue 36
On Fri, Mar 15, 2013 at 03:22:24AM -0400, bumblebritche...@gmail.com wrote: > > I don't think you guys should worry too much about messing up old decoders, Old decoders are everywhere, and not always easy to update or replace. For example: DVD players, in-car audio servers, broadcast facilities. -- -Dec. --- (no microsoft products were used to create this message) ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] flac-dev Digest, Vol 100, Issue 36
On Fri, Mar 15, 2013 at 12:42:10PM +0400, lrn1...@gmail.com wrote: > > That said, "L" could also stand for "Lossy". Should have named it > "FLLAC" - "LL" for "Loss-Less". But anyone who knows the difference between lossy and lossless will know which one the L in FLAC stands for. Everyone else can continue ripping audio from YouTube videos for listening to on their ipods (smug grin). -- -Dec. --- (no microsoft products were used to create this message) ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Higher compression modes from Flake
On Thu, Mar 14, 2013 at 08:31:34PM +0100, mva...@gmail.com wrote: > It's not a good idea, except when you want to ruin FLACs reputation. One > of the reasons FLAC is (alongside ALAC) one of the two most popular > lossless codecs is because of the well-defined subset. I've tried Flake > -9, -10, -11 and -12 on my portable years ago, and while -9 did > reasonable, anything higher would just choke the player. I found that flake at higher preset compression levels would not even produce files that the FLAC command line tool could decompress. And I 100% agree that we shouldn't change the subset, or do anything to make any existing decoder fail. > If you want more compression, you can do it yourself. The -0 through -8 > switches are just presets, you can use FLAC 1.0's -9 yourself with -l 32 > -b 4608 -m -e -E -r 16 -p on FLAC 1.2.1, there's just no shortcut -9 > anymore. I haven't studied Zopfli closely, but a similar "find the absolute best compression" iteration for FLAC is possible without altering the subset. There was some discussion on this list a few years ago about a preprocessor, but all I can find now is a preprocessor that makes WAV data easier to compress smaller (in a slightly lossy way). -- -Dec. --- (no microsoft products were used to create this message) "Mosaic is going to be on every computer in the world." - Marc Andreessen, 1994 ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Higher compression modes from Flake
On Thu, Mar 14, 2013 at 08:12:14PM +0100, mva...@gmail.com wrote: > No. If you want such things, try TAK, OptimFROG, Monkey's Audio or even > LA, you'll lose hardware compatibility anyway and they do much better > than FLAC will with a -9 option. 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 lossless audio format could (and should) have a better "bang for the buck" to the average user (who has possibly been tempted away from MP3 or WMV or some Apple format). I buy a lot of music on Bandcamp (and similar sites) and usually get smaller files (for long term storage) when recompressing (flac -8). A common sentiment I have seen online is "my CPU time is too valuable to bother with maximum compression", but that ignores the fact that all of the copies made of those files are going to add up to something bigger. A recent Google-developed algorithm called Zopfli is taking a similar approach with the old Deflate method (first used in PKZip, still used today in PNG, gzip, zlib, etc). 100% compatible with every web browser that can already decode the data. Not a new format, just the best that gzip/zlib can be. There is a huge increase in CPU requirement for compression, but that only has to be done once for each source file. http://googledevelopers.blogspot.ie/2013/02/compress-data-more-densely-with-zopfli.html "Zopfli is best suited for applications where data is compressed once and sent over a network many times, for example, static content for the web." The compressed output is "only" 3-8% smaller than the best that zlib can do, but that adds up in a lot of scenarios. If I had a Web server full of hosted sites, each with at least one copy of jquery-1.9.1.min.js.gz (or some other common static component) or a very busy PNG-heavy site, every byte saved is going to save my disk and bandwidth costs, with no penalty for the Web audience viewing the websites (and compatibility with every 21st century browser). It's almost useless for on-the-fly compression, but asymmetrical codecs often are unsuited to that anyway, even at lower compression levels. > FLAC 1.0 had a -9 option and it was > removed with a good reason: almost no gain with added decoding complexity. Thanks; I didn't know that. -- -Dec. --- (no microsoft products were used to create this message) ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Higher compression modes from Flake
On Wed, Mar 13, 2013 at 10:06:51PM -0400, ben...@winamp.com wrote: > > Flake is a completely independent codebase. When I used it years ago, I > remember it being not only better compression but significantly faster as > well. I believe some of the techniques used in libflake were added to > libFLAC in 1.1.4. However, some of the improved compression in flake was > due to options that are outside the FLAC 'subset', such as larger > blocksize, greater number of prediction coefficients, and higher-order > Rice codes. When I tested flake, it was almost shockingly fast (compared to what I was used to with FLAC) but the tightest compression options didn't produce .flac files that could play on every playback device and/or software that I tested. It is a shame that development has stopped. The next official release of the FLAC command line should really have a "-9" option for absolute maxed-out big-memory CPU-burning compression. Most general purpose compression tools have "-9" as the tightest option for compression. -- -Dec. --- (no microsoft products were used to create this message) "Mosaic is going to be on every computer in the world." - Marc Andreessen, 1994 ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Flac compression levels?
On Tue, Mar 12, 2013 at 12:36:29PM +0100, catch-...@masklinn.net wrote: > > > now is it just a coincidence, > > It is, testing on a >6mn piece (Endless, Nameless from Nirvana's > Nevermind, 6:21) Does that track have a long period of silence in the middle? (...checks Discogs...) Nope: "Endless, Nameless" comes after 10 minutes silence after the end of "Something In The Way", and all are indexed on the CD as track 12. I'm just mentioning this because I'm pretty sure that FLAC doesn't compress as tightly as it could when the source file has lots of absolute silence in it. -- -Dec. --- (no microsoft products were used to create this message) ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Commonly getting FLAC__STREAM_ENCODER_VERIFY_MISMATCH_IN_AUDIO_DATA on valid audio
On Sat, Feb 09, 2013 at 04:28:57AM -0800, bri...@sounds.wa.com wrote: > Regardless of libsndfile's architecture and design, libFLAC should by > no means duplicate the incorrect conversion. There especially should > not be an asymmetrical set of conversion factors. +1 to that! -- -Dec. --- (no microsoft products were used to create this message) ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] flac support on parrot asteroid (Android)
On Sat, Apr 28, 2012 at 12:08:15AM +0100, decentcrimi...@hotmail.com wrote: > > I have a Parrot Asteroid car media receiver that uses an Android based > operating system to function. You didn't say what Android version. Native FLAC support was added to the Android OS for version 3.1 but your device might have a stripped-down OS. The installed audio app(s) might also be designed not to use all of the native OS. > Is there anything the development crew can do to make the Asteroid stream > FLAC audio? Do you specifically need streaming, or will playing from files on local storage be enough? > the system does have an installer for 3rd party .APK files Try one of the many existing FLAC playing apps for Android. I can recommend DeaDBeeF & andLess (one of them can even play high definition FLAC files). -- -Dec. --- "Mosaic is going to be on every computer in the world." - Marc Andreessen, 1994 ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] uncompressed FLAC
On Thu, Mar 08, 2012 at 09:50:20AM -0800, gi...@thaumas.net wrote: > I wouldn't worry about it though. It's unfortunate the dbPowerAmp > developers want to take advantage of the subset of customer who don't > understand what 'lossless' means. I read some of the articles on www.audiostream.com earlier, and some of those linked from it. I can't understand the "uncompressed is better than lossless" notion either. At least with CD playback, a CD-R copy is going to be more prone to jitter (and added gaps from poorly configured rip/burn software) which does affect the sound, but comparing FLAC and WAV on exactly the same hardware should yield no difference in audio. On systems where the I/O is the bottleneck (for example, a smartphone app or hardware player with slow storage) there can be a higher risk of buffer underruns with uncompressed source material. And with a low powered CPU, there should be more of a risk of underruns with tighter compression ratios. This could explain why some audiophiles have heard better results with looser FLAC compression on the same device. But on modern (and reasonably powered) hardware, there should be no practical difference at all. -- -Dec. --- "Mosaic is going to be on every computer in the world." - Marc Andreessen, 1994 ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] encoding complexity
On Mon, Feb 06, 2012 at 07:26:19PM +0400, lrn1...@gmail.com wrote: > > Make a specification for storing this kind of data in app-block, then > devise a way to measure encoding complexity of existing FLAC stream - > and you'll be able to put these block in FLAC files that didn't have > them originally. What we're looking for is a measure of the expected decoding complexity, not the encoding complexity. The 2 are probably always going to be closely related, but they are different things, and complexity will depend on the data being compressed (aswell as on the encoder settings). There was a request last year for something similar, so that an embedded player using a CPU with adjustable clock speed (for power management) can anticipate how much CPU power will be needed for the next track or stream, before decoding begins. The idea being to adjust performance (CPU or memory) in enough time to meet demand. For known data (a music playlist using files, for example) the required metadata could be stored on the playback device, ready for the next time each track was played. For unknown data (streamed live audio) this would not be much help. -- -Dec. --- "Mosaic is going to be on every computer in the world." - Marc Andreessen, 1994 ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] FLAC Mathematical Details
On Wed, Feb 08, 2012 at 08:49:37AM -0800, gi...@thaumas.net wrote: > On 7 February 2012 21:59, Martijn van Beurden wrote: > > > Flake, another FLAC-encoders can use variable > > block length and has a algorithm to decide the length, but this is > > outside of the -0 to -8 presets, as these are all fixed block length. > > How much does the variable-block mode improve compression? I did a lot of tests about a year ago, and Flake definitely has tighter compression at the higher presets (they go up to 11, probably because 11 is one louder). I don't have the exact results to hand, but I do remember that it wasn't as much of an improvement as I had expected, and it took a lot more time to compress. Playback compatibility is not guaranteed with any of Flake's additional variable-block preset levels. I tested playback, and most software that I tried wasn't able to decode the tightest Flake compression options. The dealbreaker for me was no support for audio above 16-bit/44.1k. I regularly re-compress files to save space, and I have noticed that a lot of distributed .flac files were not compressed to the maximum level possible using version 1.2.1 of flac/libflac (or an older FLAC version was used, or both). What I should really do is test battery life with different levels of compression, as for a lot of applications that will matter more than how full the storage device can get (per hour of stored music). Latest version (according to the flake-enc website) is 0.11 (2007) but at least the Flake maintainer is active on this mailing list :-) -- -Dec. --- "Mosaic is going to be on every computer in the world." - Marc Andreessen, 1994 ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Gapless Support
On Fri, Feb 03, 2012 at 02:19:00AM +0400, lrn1...@gmail.com wrote: > > A word of caution: > 1) CUE sheets don't support timestamps past 99 minutes 59 seconds. Not > a problem for audio CDs, but for bigger media it might be an issue. Most bigger media (DVD, BD, etc) have already "solved" that problem by not relying on having a single CUE sheet, instead having a layout of files in folders (or chapters, or whatever) that isn't a 1-dimensional "follow one groove from start to finish" approach. > 2) GStreamer (which is something you might have to use as a multimedia > framework for playing audio, if you're developing free software, or > even proprietary software for some platforms) doesn't support CUE > sheets natively, and i don't really recall any frameworks that do (not > that i know that many...). CUE sheet support has to be implemented on > top of the framework, and might not be as straightforward as it sounds > (especially if you want to also have gapless playback). Clementine > audio player, for example, still can't get CUE sheets right, and > QuodLibet audio player doesn't support them at all. On an almost daily basis, I listen to FLAC files using one of these: * 2009-vintage Nokia (Symbian OS) with the FolderPlay app. * Sansa Fuze v2 (not the Fuze+) running Rockbox. Both play FLAC files gapless, and while FolderPlay claims to support CUE files I have not been able to make it work with them. If I'm not mobile, I generally use vlc for music playback. FolderPlay (not to be confused with Folder Player for Android) used to be hosted on SourceForge until the lack of source code caused it to be removed. It seems to be back now, however, with source. I have yet to come across a player that I can reliably use with single track FLAC albums, either with embedded CUE or a separate CUE file. So I either rip from CD to per-track files, or split out single track FLAC album archives to individual tracks. Buying music online is almost always per-track, and usually an album is packaged as 1 ZIP file containing all the tracks (as MP3 or FLAC or whatever was chosen). Bandcamp and MusicGlue (to name just 2) do it that way. So there isn't much room for "bonus track" trickery with online releases. The OST album of the recent David Fincher movie was released initially as a 6-track sampler (online only) then as a full album with 39 tracks adding up to almost 3 hours. Digital release was one ZIP file containing the 39 tracks (in a choice of formats, including FLAC, but not exceeding 16/44.1 resolution) and for physical release the album was split across 3 CDs or 6 vinyl discs. -- -Dec. --- "Mosaic is going to be on every computer in the world." - Marc Andreessen, 1994 ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Gapless Support
On Tue, Jan 17, 2012 at 09:44:25AM +0100, r...@noveltech.de wrote: > We are currently try to add Gapless support on our device? If we rip an CD > with our device, we can find out, that one track follow after another so we > can > recognize, that the tracks are gapless or not. Are you aiming for maximum compatibility with how the source CD would be played on an average CD audio player? Or just trying to avoid the *extra* silence that is typically added by formats like MP3 and some of the software players/libraries? As you should know, the Red Book spec allows for indexes to be used to define "pre gaps" before tracks, that are not part of the track itself. It's also possible to violate the Red Book standard and add "track 0" before the first index, or other weird tricks to include "bonus" tracks on a disc that may or may not get ripped by common software. As far as I recall, even having no silence between each track violates the standard. Many people who use FLAC to archive entire CDs (as opposed to "albums" of tracks that may or may not be on the same CD) will rip the entire disc and store it in a single FLAC file, with the CUE sheet either as a separate file, embedded in the FLAC metadata, or both. This preserves the musical "flow" of the exact timing of the music and silence across the disc, regardless of each each track boundary. > But how can we find that out on already existing FLAC files (or other > formats). Is there a marker inside the file, who tell me, that this > File is a gapless file? Also gapless make only sense, if you have the follow > up file also? A file on its own cannot really be called "gapless", however that depends on how it was ripped. If a CD has deliberate silence between tracks it's usually there for very sensible musical reasons. I have been at mastering sessions where the mastering engineer added in silence, or edited the silence that was included on the final DAT or CD-R, and asked the artist/producer to listen to the difference. Typical DAT recorders add a standard gap between tracks, and older tape formats (such as Sony PCM-F1 on Betamax) have longer and less predictable gaps. A fraction of a second added (or removed) in between tracks can make a huge difference to how an album comes across. The aim of pregaps on a CD is to allow the track skip buttons to hit the beginning of the desired track, while also having the correct gap before the track when playing through from the previous track. Strictly, that silence isn't part of any track, but to preserve the overall flow most ripping software will add the silence to the end of the previous track. That way the tracks will all start at the beginning of the music, not on silence. For some albums, this fails on tracks where the pre-gap might actually be part of an intro or a segue from the previous track. I can't think of any specific examples, but many albums of live music will have a spoken intro before some tracks (mastered in the pre-gap). > If I rip now all 4 titles and play them later the player must know, that > Song 1 is not gapless but Song2 and 3 ?Fit? together. > > What will happen, if I delete Song3?. Is the player playing now from Song2 > to Song4 gapless, which is not correct? If track 3 is deleted (or the end user removes it from a playlist, or whatever) then the "fit" (or "flow") that was there (between tracks 2 and 3 and 4) has been changed. What happens depends on where the silence was placed in each track. This is not a new problem, as the very first CD audio players had the ability to skip tracks, either by programming a crude "playlist" or with a "shuffle" function. > Anybody a good description for me, how this is solved on FLAC? The most complete "solution" is the entire CD as a single FLAC file, with CUE sheet both in the FLAC metadata and a separate CUE file. That way, all the "bonus track" weirdness can be preserved. A more flexible solution is to use 1 FLAC file per track with decisions made as to how it will sound with and without all tracks present and in sequence. -- -Dec. --- "Mosaic is going to be on every computer in the world." - Marc Andreessen, 1994 ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Git branch with compiling fixes for win32
On Wed, Nov 16, 2011 at 03:36:12PM -0800, bri...@sounds.wa.com wrote: > > This will leave Apple with even less reasons to support FLAC ... > > You make some important observations, but I do not see how anything > can be done by the FLAC team about Apple's lack of support. I think that only people who work for Apple can do anything to persuade Apple to (ahem) think different about FLAC. I'm guessing there is a strong "Not Invented Here" effect at work. > As for FLAC, no news is good news. That means the code is stable and > bug free. I appreciate that, a lot. That's why I run mostly Debian or Ubuntu LTS on machines that need to be stable (but don't need to have the latest fancy stuff). Unfortunately, most people tend to prefer the latest fancy stuff (in devices and installed software) so for those people lack of change is usually seen as a bad thing. Although having said that, last time I had to install FLAC on a Windows PC (someone else's) the GUI front-end that I downloaded came with an older flac.exe than the current FLAC version at the time. > It seems that all of the recent updates have been efforts to port > FLAC to operating systems like Windows and Linux. In terms of your > comments above, Windows/Linux support does absolutely nothing to help > FLAC compete against ALAC on the OSX platform. Not directly, no... ...but most people like New Stuff as opposed to not fixing something that isn't broken. Enough to cause more interest in Apple Lossless as a supported format (outside of Apple devices) and therefore less interest in FLAC. It could even cause some music download sites to reconsider their support of FLAC. > It is indeed noteworthy that Apple has released the source for ALAC. > The power of FLAC is that it was designed for embedded systems from > the beginning, and that's why you see portable recorders like the > Sound Devices 700 Series supporting FLAC, as well as various optical > disc players (CD, DVD, etc.). One question that remains for me is > whether Apple's ALAC open source can be ported to these kinds of > embedded systems with the same ease. I wish I could afford a portable recorder from Sound Devices! They record multichannel or stereo in FLAC aswell as playing it, right? Obviously, FLAC requires much less horsepower to decode than to encode, and that's OK (for most uses) because the decode will happen more often. I can live with uncompressed recording, but when buying hardware, FLAC support is always a deciding factor. However, almost every device that can play audio (from el-cheapo DVD players, to almost every "pro" DJ or broadcast deck) is able to play MP3 files. Most of them can also play WMA and AAC (lossy), but FLAC support on mass-market devices is rare. There is such a huge variety of chipsets and other hardware elements that it's impractical to port Rockbox to them. For example, OPPO do some very nice DVD and BD players for the home theatre and audiophile markets. But only their top-range players can play FLAC files. That is according to their own website, but it may be a "hidden extra". Similarly, CD DJ decks from Pioneer and Denon seem to support every lossy compressed audio format, but not lossless. And to make it even worse, Silvio Zeppieri (Denon brand manager) commented on www.denondjforums.com (in Feb 2010) that their reason for not supporting FLAC was that hard drives are cheap now, so just use WAV for "lossless" instead, as it would cost Denon too much to develop FLAC support. FolderPlay (app for Nokia S60) is what I listen to music with on the move every day (mostly FLAC, some MP3) and the developer told me that it took him half a day to add FLAC support. Whereas Denon were afraid that the DJ features (scratch, loop in/out points, etc) that are already possible on Denon hardware in WAV, will cost them too much development time to support in FLAC. What impressed me most about the discussion on www.denondjforums.com wasn't the overall defeatist attitude from a Denon manager (he said "no direct FLAC sales" in Feb 2010), but that most of the other people on the forum agreed that hard drives are so cheap that lossless has no real advantage: digital DJs should either use MP3s (not caring about sound quality) or WAV (not caring about storage space). And now we find ourselves in a world where hard drives are suddenly not cheap anymore... -- -Dec. --- "Mosaic is going to be on every computer in the world." - Marc Andreessen, 1994 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[Flac-dev] Bug: end-of-line in FLAC console output
On Wed, Nov 16, 2011 at 03:36:12PM -0800, bri...@sounds.wa.com wrote: > As a seasoned software developer, I've learned the hard > way that every single change to a source code repository is a chance > for a new or old bug to appear. I am not aware of any bugs in FLAC, > so the lack of changes is perfect. The only bug I'm aware of is the end-of-line one, where the command-line utility's output goes one character further than it should, resulting in extra scrolling when the output is too long for the console. Anyone using a FLAC front-end will not even be aware of that, and I am guessing that most possible fixes might break any of the existing front end tools that depend on this behaviour. -- -Dec. --- "Mosaic is going to be on every computer in the world." - Marc Andreessen, 1994 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Git branch with compiling fixes for win32
On Wed, Nov 16, 2011 at 05:41:21AM -0800, avu...@gmail.com wrote: > Hate to be Capt. obvious here, but there's a lot of development going > on here that should be encouraged. If the FLAC project isn't going to > open up, it would make a lot of sense for someone to take over > maintenance on a github account with the git-cvsimport or such. I > don't see anyone stepping up, me included, but I wanted to throw this > out there in case someone hasn't really thought about it yet. Looking at the FLAC website, the most recent news is almost 2 years old, and there's no evidence to show that the project's still live. I haven't seen any post from Josh Coalson on this list in a while: is he still running the project? Something else to think about: Apple recently released sources for Apple Lossless reference utilities. It's all under an Apache license. This will (presumably) lead to more software developers spending more time improving ALAC support in their projects, with more reference material available than the unofficial reverse-engineered code (as used in vlc and libavcodec). This will leave Apple with even less reasons to support FLAC in their own products. Anyone with an iPad/iPhone/iPod must install Rockbox to play FLAC files, and the Apple TV can only play FLAC (and anything that was not bought from iTunes) using XBMC, after being jailbroken. But for the Average End User, they don't want to have to jump through a bunch of hoops to get FLAC support. Apple Lossless will Just Work on all Apple devices (as it always did), but now it's more freely available so the freedom-loving hippies can stop complaining about the source code. -- -Dec. --- "Mosaic is going to be on every computer in the world." - Marc Andreessen, 1994 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Variable Bit Rate
On Mon, May 23, 2011 at 12:09:26PM -0700, denn...@chronometrics.com wrote: > Brian... > You've been both polite and helpful. Thanks. I think everyone on this thread has been both polite and helpful. When you ask a very open question like "how can it be truly lossless?" you should expect that some people are going to assume that you know little about data compression, because you didn't say otherwise. It might have been more useful to describe your intended application, or read some of the list archives. There have been some very thorough and detailed discussions here about high-def (as in better than CD) FLAC streaming and playback CPU speed scaling in the past few months. > What I was looking for was > confirmation that a properly designed application would decode FLAC > without temporal issues. That wasn't clear from your original post. -- -Dec. --- (no microsoft products were used to create this message) ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] hi, what is the difference between flac encoder and decoder
On Wed, Jan 12, 2011 at 12:46:45PM -0800, aziz_8...@yahoo.com wrote: > > hi,i would like to ask on what is the difference between flac encoder and > decoder The encoder encodes, and the decoder decodes. Block diagrams: .wav --> ENCODER --> .flac .wav <-- DECODER <-- .flac -- -Dec. --- (no microsoft products were used to create this message) "Mosaic is going to be on every computer in the world." - Marc Andreessen, 1994 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] FLAC is dead?
On Mon, Jan 10, 2011 at 02:59:23PM -0500, grarp...@gmail.com wrote: > Sure, basics :) Again, I'm meaning in regard to about bugs, docs, > porting and nits. And packaging by OS distributions (making the RPM and DEB files). > Yep, if you can get their TOC tables to agree. cdparanoia, eac and > cdda2wav do differ at times with this. It took raw scsi/ata commands > to figure out who was right. A minor example of an unfixed fixable. The various CDDB databases (and more accurate sites like Discogs) have more than unreliable TOC reading to worry about. When ripping using abcde, I regularly have to choose between 2 or more freedb choices where different users typed in different versions of song titles. And that's without taking into account bonus tracks or reissue/remaster jobs that change the durations of what should be the same tracks in the TOC. > So it's the only feasible explanation for the starvation, unofficially > official. > http://www.panasonic.com/consumer_electronics/technics_dj/prod_default_analog.asp The best explanation I read (and I spent a few hours over the weekend reading assorted blogs and web boards) is that they no longer have them in constant production, so the prices can go up and down depending on the global supply. Just because they are not making them *today* does not mean they have stopped, and market supply/demand explains the sane price becoming less sane. > Not quite. Only the Stanton ST.150 competes at par. I recently tried > both side by side and went ST.150. It is a solid tank. Have you tried using the Audio Technica AT-PL120 deck? I've read a lot of reviews based on "we looked at pictures of it" but nothing based on using it. Of all the also-ran decks, it's one of the closest in looks to the Technics range. -- -Dec. --- (no microsoft products were used to create this message) "Mosaic is going to be on every computer in the world." - Marc Andreessen, 1994 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] FLAC is dead?
On Mon, Jan 10, 2011 at 12:54:35PM -0800, bri...@sounds.wa.com wrote: > Fortunately, FLAC is free. It cannot be priced out of the market. But companies like Apple can refuse to support it, out of "Not Invented Here" ass-headedness. Companies like Denon (and actually all of the CDJ manufacturers) don't have the excuse of having their own formats to promote: Pioneer have a CDJ deck that can play CDDA or files on CD discs or files from attached USB mass storage device or SD card, but it can't play FLAC even though it's royalty-free and relatively easy to support. It can play MP3 and WAV and AAC, but not FLAC. Denon's excuse (on their own support forum) is that maybe there might be some kind of lawsuit in the future, and they don't want to support FLAC and not have their asses covered against some vaguely possible future threat. So do all the hand-waving you want, Denon, you're not getting any of my money! > Speaking of ripping vinyl to FLAC, I would expect that a belt drive > would be better than direct drive. There's a common misconception that direct drive == bad, due to many cheap and nasty DD decks in the late 1970s or early 1980s from "also ran" vendors who wanted a DD deck in their product ranges. The motor used in the 1200/1210 decks is a very close relative of the Technics SP10 that most vinyl cutting lathes use. With a modest investment in hardware mods, you can turn a stock 1210 or 1200 into an audiophile deck for not a lot of money (on the audiophile spending scale). -- -Dec. --- (no microsoft products were used to create this message) "Mosaic is going to be on every computer in the world." - Marc Andreessen, 1994 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[Flac-dev] Silent All These Years
On Fri, Jan 07, 2011 at 04:36:30PM -0800, bri...@sounds.wa.com wrote: > > This thread has raised several good topics. It's surprising that the > FLAC-Dev list has been silent for years, and now suddenly there are > several good ideas to discuss. I signed up more than a year ago, to report the "end of long line" problem, and had planned to lurk on the list before firing off a n00b question. As I hadn't even looked at the source since well before version 1.2.1 was released, I wasn't sure how much the list was going to be "developer issues only, read all the source first". -- -Dec. --- (no microsoft products were used to create this message) "Mosaic is going to be on every computer in the world." - Marc Andreessen, 1994 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Spinal Flac
On Fri, Jan 07, 2011 at 09:16:22PM -0500, brianmwat...@gmail.com wrote: > > > I was wrong about it going up to 11 - it actually goes up to 12. > > Too bad. I thought for a minute there that it goes up to eleven > because... "Well, it's one louder, isn't it? It's not ten. You see, I was aware of the Spinal Tap reference in having it go up to 11, and maybe that's what caused me to remember it wrong (most of the benchmarks on the Flake website go up to 11, but not up to 12). > Oh well. They missed out on a great movie reference, and in audio software too! -- -Dec. --- (no microsoft products were used to create this message) "Mosaic is going to be on every computer in the world." - Marc Andreessen, 1994 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] FLAC is dead?
> Oh I don't doubt the basics, red book is red book and bits are > identically replicable and re rippable bits. I don't see any problem with taking innovation as far as is practical and saying "it's finished, no more updates". I'm not expecting FLAC or cdparanoia to be able to integrate with FaceHugger, or even to be able to query track titles online. If I want to do freedb lookups, I can use abcde (in text mode) or any of the GUI rippers, most of whom use flac and cdparanoia as back-end utilities. I like the idea of software that just works and doesn't need any further refinement. Similar to hardware that's built to last (see below)... > Guess what? Technics patent expired, they failed to innovate and > left the market. Now we have an OEM fill-in led, in example, by > perhaps the Stanton ST.150. A new wrapper on the old LP core. I'm not sure about the patents, but the Technics 1200 and 1210 series turntables are still in production, out of the same factory in Japan. They have definitely not left the market! Stanton and other brands are playing "also ran" with direct drive or belt drive turntables that just aren't as good. Even with new decks easily available, secondhand Technics change hands for high prices because they represent some of the best engineering and quality of manufacture. They are built to last and don't need to be replaced. There have been many rumours about Technics going out of production over the years, and the most recent one was based on an announcement that 2 mid-range models in the 1200/1210 range were ceasing production. These rumours are usually started by someone who has a load of new turntables in stock, and wants a panic in the marketplace to help shift them at a higher price. If you have news that Technics have definitely ceased production, please link to an official website. That has very little to do with FLAC but I wanted to clear it up. -- -Dec. --- ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] decoder block diagram
On Sun, Jan 09, 2011 at 06:07:29AM -0800, aziz_8...@yahoo.com wrote: > > hi i would like to know how to get the decoder block diagram for FLAC, is it > possible to get it from the encoder? if yes how? You asked the same question 2 weeks ago, and got an answer. I gather (from that reply) that you need to write the block diagram yourself, using the available documentation. -- -Dec. --- (no microsoft products were used to create this message) "Mosaic is going to be on every computer in the world." - Marc Andreessen, 1994 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Idea to possibly improve flac?
On Fri, Jan 07, 2011 at 05:11:26PM -0800, bri...@sounds.wa.com wrote: > Lots of comments throughout this one... And I'm going to cherry-pick a few replies as it's getting late. > What I found most interesting was that I had > hired a professional studio in Seattle, and the owner actually stuck > his head in the room for this one track. He'd heard a lot of > interesting music in the local scene, but nothing that messed up. My friend's band was some kind of Metal, so you might expect most of their fans to be nearly deaf, or unable to tell the difference. But most of them did. All their previous stuff was recorded and mixed (and then released) on analogue cassette, and sounded way better. DCC was still pretty new at the time, so he chose to "upgrade" the portastudio to DCC instead of MiniDisc, because DCC was backwards compatible with cassette. [NIN 24/96] > Thanks! That's interesting to note. I think that I ended up with > the true 24/96 files, but I am curious: How do you tell whether you > have the full 24/96 or not? Extract to WAV, do a hex dump, and look for repeated 0x00 bytes. Someone on the hydrogenaudio forums did that, reported it on the NIN forums, and Reznor got the reissued 24/96 FLAC'd and seeded on tracker.nin.com in a couple of days. > 16-bit audio samples stored in a 24-bit file format. Frequency > analysis makes it obvious whether the content extends above 20 kHz. Google for that hydrogenaudio thread: Reznor made one post on it, and mentioned that the recording was done at both 24/96 (Lavry) and 24/192 (Apogee) on all songs, and they chose whichever they preferred at mix time. > If Flake is only an > encoder, and compression levels above 8 are not guaranteed to be > compatible, then what's the purpose? If Flake cannot decode, then > what good is it to create a file that no other decoder can handle? Because it (hopefully) produces compatible FLAC files that can be decompressed by any FLAC decoder out there. It's still at version 0.11 and is intended as an alternative to the reference encoder. I knew about it, but didn't try it until it popped up in my Ubuntu package manager when I was searching for something else. http://flake-enc.sourceforge.net The extra stuff it does is variable block size encoding (which is legal according to the spec, just not implemented in the reference encoder. If you try the higher compression levels there is a warning that the files created might not work with all FLAC decoders. I can understand working on an alternative encoder first, because if it is to remain true to format, any decoder should always be able to work on what it creates. The metaflac tool will display what encoder was used to create any FLAC file. I was wrong about it going up to 11 - it actually goes up to 12. But like the reference encoder, those levels are just shortcuts to more complex options (prediction type, block size, etc). My first test was a 16-minute WAV ripped from CD, encoded at all the compression levels that Flake has, and then tested using flac -t (and they all passed). However they were all bigger than what flac -8 produces, so I have done no more testing. I really need to throw more varied music at it, then load it all up on a microSD card and see if any hardware players cannot deal with the higher compression levels. But if there isn't an appreciable reduction in size then I won't be changing over from the reference encoder. > Every time I see the long filenames > issue, I worry that there is a problem, until I remember that this is > a known issue and just ignore it. Thanks, I thought it was just me... > Anyway, the flac command-line should be improved, even though the > file format and library are probably just fine being left alone. The format should definitely remain frozen: that was one of the founding principles of the ARJ compressor, after widespread confusion when PKZIP 2.0 was released (older versions of PKUNZIP could not deal with the new compression methods). -- -Dec. --- ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Detecting lossy encodes
On Sat, Jan 08, 2011 at 12:54:01AM +0100, jor...@anion.no wrote: > > I think we agree now on that the "find mp3 before encoding" feature would not > be a good idea to implement in the flac core. As Brian pointed out, it might > be a better idea to create a program that automatically checks if a flac > might have been an mp3 source. It would be more versatile to check if the uncompressed audio was taken from a lossy source. And you'll be doing that anyway, just using libFLAC to decode it first. With all lossless encoding, we can be 100% sure that the uncompressed audio that we get out was the same as what went in, so only checking a FLAC file limits any tool to only working with FLAC. There's one for Windows called EncSpot, and I just don't remember the names of any of the others (but there are others). I'd suggest grabbing as many of these as possible and especially those with source code available, before reinventing the wheel. Just as home taping (and vinyl bootlegging) resulted in many generations of copies, I'm sure there are MP3 files floating around that were ripped from CD, encoded at a low bitrate, burnt to CD, copied CD-to-CD on audio CD recorders, and ripped again. It might be easy to fingerprint which MP3 encoder was used (and at what settings) for uncompressed source audio, but I'd be really impressed if anyone could analyse an MP3 or other lossy file that had been transcoded more than once. > Another test, if the FFT test is unclear, is to check the correlation between > left and right channel below 3kHz You need to be careful about stereo separation at lower frequencies. Every vinyl lab checks this, and almost every mastering house has warnings about it on their website. Due to the frequency response of vinyl as a medium, bass has to be cut when recording, and boosted at playback. The RIAA standardised the vinyl frequency response curves back in the 1950s or so - before that there were competing systems using variations on the same frequency curve. As stereo vinyl is cut at 45 degrees for mono compatibility (a form of mid side encoding) the difference signal translates into vertical stylus movement. So the needle will jump out of the groove if there is too much separation at lower frequencies. As the human hearing can't really tell direction with lower frequencies, it's not as essential. This same shortcut is why most movie "surround sound" systems have only one sub bass channel. -- -Dec. --- ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Piracy and FLAC
On Fri, Jan 07, 2011 at 11:59:26PM +0100, cy...@nuclex.org wrote: > > > I also agree with you on these points you mention. If you guys are familiar > > on how the piracy groups work on the internet, you are aware that they have > > "releases" with their names on it. In the piracy "scene", some groups are > > competing on getting the first release out, and could only be beaten by > > another group releasing another higher quality release. Even if 2 groups were racing to be first out the door with the latest Katy Perry CD, something like lower FLAC compression is going to make less of a time difference than using a faster computer, or doing encodes in parallel across more than one computer. > > Some of these groups or individuals are young people, tinking that they > > know everything. My idea was based on this. It would be fun stopping this It would be absolutely futile stopping "this"! Most people enjoy a puzzle or a challenge, and many in the pirate "scene" take pride in breaking (or, to coin a phrase, cracking) every puzzle and challenge that gets in their way. Tarring everyone with the same brush who shares music online isn't going to help FLAC in any way. That's supposed to be what this list is for. > ... that really sucks. Pirates giving a genuinely great codec a bad name > because of the way their ecosystem promotes treachery. Though I wonder > if they wouldn't self-regulate by requiring EAC .logs or something like > that? It doesn't take much "research" to go onto pretty much any torrent (or other sharing) site, search for FLAC files, and look at all the comments from MP3 fans (and iPod owners) who do not want FLAC files and cannot understand how anyone would bother with such a big file format, for the sake of some improvement in sound quality that most people don't notice. And they usually aren't polite about it. When the ARJ format became popular, software pirates started using it in preference to ARC or ZIP. Then whatever had the tightest compression was the flavour of the week, leading to the popularity of RAR for many years and now 7Zip is becoming as popular. At least according to NNTP server stats that I have been reading for more than 10 years... None of those data compression formats were made "for" pirates, they just happened to be used by a lot of the "scene", and any "bad name" that they might have had by association was/is entirely subjective. The same should go for FLAC in audio. > I think an simple tool that is run on existing FLAC files and gives a > clear good/bad answer (perhaps with a probability to remain fair) could > spread like wildfire amongst audiophiles if publicized in the right > channels. There have been a few such tools, and some of them show up in the comments of FLAC releases on that Swedish torrent site as indicators of quality... And there will never be a clear good/bad answer. Which is in itself a form of "copy protection"! Personally, if I want to hear music at its best resolution and dynamic range, I go out and hear it played live. -- -Dec. --- ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Idea to possibly improve flac?
On Fri, Jan 07, 2011 at 02:22:51PM -0800, bri...@sounds.wa.com wrote: > > First of all, I am not aware of any official source of FLAC files > that provide MP3 sourced data. Unofficial sources (such as Usenet and that torrent site with the old fashioned sailing ship as its logo) are much more likely to have FLAC files that were made from lossy audio. And I vaguely remember reading about an illegal download site that stored all audio in MP3 (at less than 320k) and transcoded on the fly for all other bitrates and formats, including FLAC and 320k MP3. They did it to save storage space. > However, you should be aware that many modern producers use software > to create their music, and when the software stores sound clips in > MP3 format, what you end up with is music that sometimes looks like > MP3. I recently bought the double-CD "Influence" remaster by The Art Of Noise and some rarer tracks were sourced from MP3 because that was all their archivist could find. Most of the reissue was direct from analogue tapes so this wasn't a quick "shovelware" reissue job. > it just has to do with the software that was used to create the music > originally. A friend of mine recorded his band's last album on DCC in the mid 1990s and released it on CD. It sounds horrible; the lossy compression of DCC is even worse than MiniDisc's ATRAC. I'm sure this CD would fail most FFT quality tests, as literally everyone who heard it (not just people with "golden ears" or good sound systems) complained about the quality. > In other words, if you try to shut down the FLAC encoder based on an > FFT, you might have a lot of false triggers! I think it's a bad idea for a lot of reasons: checking the source audio quality should be a job for another tool. Most FLAC users won't need to check (most of my FLAC files are ripped from original CDs that I own), and anyone who was trying to fool listeners (or fellow piracy groups) would either work out how to bypass the check, or (more likely) use an older version of FLAC. And it's not in keeping with the philosophy behind FLAC: one thing that I regularly say to people who aren't sure about using FLAC is that Josh designed it with no copy protection support: if it was there, someone would only crack it, so it is effectively useless. And that's probably why Apple's ALAC is usually bigger than FLAC for the same uncompressed audio (and why Apple still don't support FLAC in their products). Stopping a pirate from encoding FLAC is similar to stopping a pirate from ripping a copy-protected CD: it's a challenge to be overcome, and it will probably take "them" less time to work it out than it took "us" to build it. And "they" only need to work it out once. Which is why all copy protection and DRM sucks, for everyone. > Nine Inch Nails who provide FLAC files. The initial free online release of NIN's The Slip had a problem with the 24-bit version: it wasn't the full 24/96. Turns out it was a genuine oversight by the mastering lab (who used the 24/96 to master the vinyl), and the true 24/96 files were reissued less than a week later. So even with the artist fully behind 24-bit FLAC, and doing almost all of the work in their own studio, things can still go wrong. > People are selling hardware devices in droves, and > they cannot afford to change their firmware every time some random > change happens in the FLAC source. It's actually way better that > FLAC is not changing. The FLAC source can change without violating compatibility. Faster or more efficient encoding can still produce compressed data that older decoders can process. > Some audio turns out smaller with ALAC, other audio turns out > smaller with FLAC. Overall, the average performance is identical. I've been trying Flake (an alternative FLAC encoder; all it does is encode) recently and while it goes way faster than the reference FLAC encoder in terms of speed, the first encode I tried with it ended up larger than with the reference encoder, at all compression levels. The compression levels in Flake go up to 11, but past 9 or 10 there is no guarantee of full compatibility for playback. > Many tools run the > command-line flac utility behind the scenes. Others use the FLAC > library directly. About a month ago I was setting up FLAC support for a friend on a Windows PC. Almost every GUI front end (based on the latest available download) that I tried was using an out of date version of the FLAC binary or library, and had the default compression set to -6 or lower. There is no excuse for not cranking up the compression level on any modern computer: surely you want to get the files as small as possible? > I doubt there would be any professional > interest in changing things just for the sake of change or "newness." The only "new" thing I want in FLAC is a fix for a minor bug in the way the command line tool treats the end of line. If long filenames push the "percent complete" past the screen width and you
