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
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 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] 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] 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 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
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
[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 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] 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] 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] 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] 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
[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 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
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] 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] 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] 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
[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] 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 are encoding or testing a lot of files,
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
