Re: [Flac-dev] Idea to possibly improve flac?
> Regarding dithering, I am not aware of many programs that do that without > very specific user selection. Any user savvy enough to turn on dithering > would hopefully be paying attention well enough to avoid promoting 16-bit to > 24-bit without noticing their mistake. I suspect that this is sometimes done dishonestly in order to sell hi-fi enthusiasts DVD-A's made from lower-quality source material. After all, they do sell $35 dollar "high definition" digital coaxial S/PDIF cables at your local Radio Shack. And you lost me on the last paragraph there, but that's okay. Thanks for the clarification. - BW On Sat, Jan 8, 2011 at 1:13 AM, Brian Willoughby wrote: > > On Jan 7, 2011, at 21:38, Brian Waters wrote: >>> >>> My 16-bit detector does exactly that, except that it only looks for >>> 0x00 in the lowest 8 bits of each sample. >> >> What if the program that did the 16-to-24 conversion also did some >> dithering? If I'm not mistaken, that would probably be the case if >> they did some sample rate conversion as well (maybe they were going >> from CD quality up to 24/96). In that case, shouldn't your program >> look for values in the LSB that are under a certain threshold, instead >> of just zeros? > > That's a very good suggestion, and would be appropriate for a more advanced, > but fuzzy detection. > > My program was designed to catch the absolute simplest case of setting your > DAW to 24-bit files when recording from a 16-bit interface. Or, if you have > a 24-bit digital audio interface, but feed it from a DAT. > > In fact, the day I wrote the program was when I was transferring an > 18-channel live recording that I made for a band that wanted to tour Europe > based on a live demo, where 16-channels were 24-bit A/D and the extra 2 > channels came from my old DAT via AES/EBU. Even though I knew that the DAT > channels couldn't possibly be full 24-bit, I still wanted to confirm that I > would not lose anything by converting the master files to 16-bit. I archive > all recordings using FLAC to save space, and a 16-bit FLAC would obviously > take less room than a 24-bit FLAC. > > > Regarding dithering, I am not aware of many programs that do that without > very specific user selection. Any user savvy enough to turn on dithering > would hopefully be paying attention well enough to avoid promoting 16-bit to > 24-bit without noticing their mistake. > > Regarding 16/44.1 up-conversion to 24/96, I would notice that in the FFT, > because there would be nothing but very low-level quantization noise above > 44.1 kHz. But this sort of thing is a manual process for me now, not > automatic. I imagine that it would be especially difficult to detect > aliasing in an up-conversion, at least with software, but it's almost > completely obvious to a human looking at the linear frequency FFT display. > By the way, the 44.1 kHz to 96 kHz conversion would create valid 24-bit > samples - there would be nothing "16-bit" about them any more. Because of > the change in sample rate, the 16-bit values would fall in between sample > periods, and thus the exact sample would hopefully use the full 24 bits for > maximum accuracy. In my opinion, all sample rate conversions should > preserve the 24-bit results. > > As for your suggestion to look for values in the LSB under a certain > threshold, I think that you have a misunderstanding about dither. The LSB > would always be changing in dithered material, regardless of amplitude > thresholds. Dither has to be applied to all samples, loud or quiet, or else > it doesn't do its job. In other words, dithered audio is going to have > constant motion in the LSB. I do think that a dithered 16-bit file stored > in 24 bits might have some patterns, such as perhaps all 1s or all 0s, but > there's no guarantee. Dithering starts by adding noise, and so the > intermediate result has valid bits everywhere. When the dither process is > complete, the result should be masked so that the 8 LSBs are all 0, but if > the masking isn't done then they really could be anything. I have noticed > interesting patterns with bit meters, but I'm not sure whether to trust a > bit meter that I did not write myself, as the two I have used show > completely different pictures of the same digital audio stream. > > Brian Willoughby > Sound Consulting > > ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Idea to possibly improve flac?
> My 16-bit detector does exactly that, except that it only looks for > 0x00 in the lowest 8 bits of each sample. What if the program that did the 16-to-24 conversion also did some dithering? If I'm not mistaken, that would probably be the case if they did some sample rate conversion as well (maybe they were going from CD quality up to 24/96). In that case, shouldn't your program look for values in the LSB that are under a certain threshold, instead of just zeros? Again, forgive me if I'm misinformed here, this isn't really my specialty. - BW On Sat, Jan 8, 2011 at 12:31 AM, Brian Willoughby wrote: > > On Jan 7, 2011, at 18:08, Declan Kelly wrote: >> On Fri, Jan 07, 2011 at 05:11:26PM -0800, bri...@sounds.wa.com wrote: >> [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. > My 16-bit detector does exactly that, except that it only looks for > 0x00 in the lowest 8 bits of each sample. I used to use hexdump, but > didn't trust my eyes when scanning manually. With a program, there > aren't any false positives for 0x00 bytes in other positions. What > it does is scan until the first sample is found with something in the > lowest 8 bits, and then reports the file as true 24-bit and quits > early. If it scans the entire file without finding any 24-bit > values, it gives the sad news that it's really 16-bit samples > disguised as 24. > > By the way, I had to special-case 0x0081 and treat it as 16-bit. > I don't know whether it was the MOTU 896HD or Logic, but something > was creating that one value in the midst of an otherwise 16-bit pure > file. But there are tens of millions of other 24-bit values, so > ignoring that one won't create a false report. > > >>> 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. > > Thanks. > > Brian > > ___ > Flac-dev mailing list > Flac-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/flac-dev > ___ 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 Jan 7, 2011, at 18:08, Declan Kelly wrote: > On Fri, Jan 07, 2011 at 05:11:26PM -0800, bri...@sounds.wa.com wrote: > [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. My 16-bit detector does exactly that, except that it only looks for 0x00 in the lowest 8 bits of each sample. I used to use hexdump, but didn't trust my eyes when scanning manually. With a program, there aren't any false positives for 0x00 bytes in other positions. What it does is scan until the first sample is found with something in the lowest 8 bits, and then reports the file as true 24-bit and quits early. If it scans the entire file without finding any 24-bit values, it gives the sad news that it's really 16-bit samples disguised as 24. By the way, I had to special-case 0x0081 and treat it as 16-bit. I don't know whether it was the MOTU 896HD or Logic, but something was creating that one value in the midst of an otherwise 16-bit pure file. But there are tens of millions of other 24-bit values, so ignoring that one won't create a false report. >> 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. Thanks. Brian ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Synchronizing a streaming client to the server Was: Idea to possibly improve flac?
Give it a go, I await your results :D On Sat, Jan 8, 2011 at 12:20 AM, Brian Willoughby wrote: > Well, in that light, I suppose it isn't reasonable to expect people to wait > 23 seconds for their internet streaming broadcast to start playing. > > Then again, maybe it could be sold as the "price" for lossless streaming! > ;-) > > Seriously, though, what about if the Ogg page is not part of the picture? > i.e., what about just using pure FLAC and IP? > > Brian Willoughby > Sound Consulting > > > On Jan 7, 2011, at 20:49, David Richards wrote: >> >> The actual non made up number for 44100 is 23 seconds. :D >> >> 4096 samples, 254 packets in an ogg page. > > > ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Synchronizing a streaming client to the server Was: Idea to possibly improve flac?
Well, in that light, I suppose it isn't reasonable to expect people to wait 23 seconds for their internet streaming broadcast to start playing. Then again, maybe it could be sold as the "price" for lossless streaming! ;-) Seriously, though, what about if the Ogg page is not part of the picture? i.e., what about just using pure FLAC and IP? Brian Willoughby Sound Consulting On Jan 7, 2011, at 20:49, David Richards wrote: > The actual non made up number for 44100 is 23 seconds. :D > > 4096 samples, 254 packets in an ogg page. ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Synchronizing a streaming client to the server Was: Idea to possibly improve flac?
The actual non made up number for 44100 is 23 seconds. :D 4096 samples, 254 packets in an ogg page. -David On Fri, Jan 7, 2011 at 11:44 PM, Ben Allison wrote: > The main problem is in the Ogg layer, in my opinion. > > Imagine this extreme use-case with __completely made up__ numbers. This > is a scenario where the server is encoding to FLAC on-the-fly from a raw > PCM input, either from disk or a live stream. > > Let's say the FLAC block size is 1024 samples, or 23ms at 44100 Hz. > Let's say each silent block compresses to 1 byte. Let's also say that the > Ogg packeting layer wants 4096 bytes before creating a page. Again - > these numbers are completely made up, but illustrate the point. In this > example, it would take 95 seconds of digital silence before Ogg decided to > send another page out over the network. > > If the input audio on the server is coming from a live-source (such as > simulcast of an FM station) or if the disk I/O is very slow, this can be > extremely problematic. > > Ben Allison > Principal Software Engineer > Nullsoft, Inc. > >> I just thought of something: Given the maximum supported network >> packet size, and the minimum number of channels (probably stereo) for >> a FLAC broadcast stream, it should be possible to calculate the >> absolute longest time that a single network packet could span. Once >> you know that time, you could simply double it, and then make sure >> the streaming client always buffers up at least that much time before >> playback is started. Voila - instant protection against starvation >> due to silent frames being compressed to ultra-tiny packets with a >> long delay. >> >> Some of the comments here have talked about low latency, but I would >> say that low latency has no place in an internet streaming >> broadcast. I mean, the listened have no frame of reference for >> latency anyway, so what does it matter if the latency is really high? >> >> Now that I think about it this way, I'd say that FLAC and OggFLAC >> should not have any real problems due to compression of silent >> frames. Any place there is a problem should be blamed on bad >> streaming client / player code, not on the format itself. >> >> Brian Willoughby >> Sound Consulting >> >> ___ >> Flac-dev mailing list >> Flac-dev@xiph.org >> http://lists.xiph.org/mailman/listinfo/flac-dev >> > > ___ > Flac-dev mailing list > Flac-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/flac-dev > ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Synchronizing a streaming client to the server Was: Idea to possibly improve flac?
The main problem is in the Ogg layer, in my opinion. Imagine this extreme use-case with __completely made up__ numbers. This is a scenario where the server is encoding to FLAC on-the-fly from a raw PCM input, either from disk or a live stream. Let's say the FLAC block size is 1024 samples, or 23ms at 44100 Hz. Let's say each silent block compresses to 1 byte. Let's also say that the Ogg packeting layer wants 4096 bytes before creating a page. Again - these numbers are completely made up, but illustrate the point. In this example, it would take 95 seconds of digital silence before Ogg decided to send another page out over the network. If the input audio on the server is coming from a live-source (such as simulcast of an FM station) or if the disk I/O is very slow, this can be extremely problematic. Ben Allison Principal Software Engineer Nullsoft, Inc. > I just thought of something: Given the maximum supported network > packet size, and the minimum number of channels (probably stereo) for > a FLAC broadcast stream, it should be possible to calculate the > absolute longest time that a single network packet could span. Once > you know that time, you could simply double it, and then make sure > the streaming client always buffers up at least that much time before > playback is started. Voila - instant protection against starvation > due to silent frames being compressed to ultra-tiny packets with a > long delay. > > Some of the comments here have talked about low latency, but I would > say that low latency has no place in an internet streaming > broadcast. I mean, the listened have no frame of reference for > latency anyway, so what does it matter if the latency is really high? > > Now that I think about it this way, I'd say that FLAC and OggFLAC > should not have any real problems due to compression of silent > frames. Any place there is a problem should be blamed on bad > streaming client / player code, not on the format itself. > > Brian Willoughby > Sound Consulting > > ___ > Flac-dev mailing list > Flac-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/flac-dev > ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Synchronizing a streaming client to the server Was: Idea to possibly improve flac?
On Fri, Jan 7, 2011 at 11:25 PM, Brian Willoughby wrote: > I just thought of something: Given the maximum supported network > packet size, and the minimum number of channels (probably stereo) for > a FLAC broadcast stream, it should be possible to calculate the > absolute longest time that a single network packet could span. Once > you know that time, you could simply double it, and then make sure > the streaming client always buffers up at least that much time before > playback is started. Voila - instant protection against starvation > due to silent frames being compressed to ultra-tiny packets with a > long delay. > > Some of the comments here have talked about low latency, but I would > say that low latency has no place in an internet streaming > broadcast. I mean, the listened have no frame of reference for > latency anyway, so what does it matter if the latency is really high? You can say that but I can also stick my fingers in ears and whistle whilst you do. 2kb of ram is enough for anyone... > Now that I think about it this way, I'd say that FLAC and OggFLAC > should not have any real problems due to compression of silent > frames. Any place there is a problem should be blamed on bad > streaming client / player code, not on the format itself. Its not in the format or the client / player code. Its in libflac as I have pointed out. -David > > Brian Willoughby > Sound Consulting > > ___ > Flac-dev mailing list > Flac-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/flac-dev > ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Synchronizing a streaming client to the server Was: Idea to possibly improve flac?
I just thought of something: Given the maximum supported network packet size, and the minimum number of channels (probably stereo) for a FLAC broadcast stream, it should be possible to calculate the absolute longest time that a single network packet could span. Once you know that time, you could simply double it, and then make sure the streaming client always buffers up at least that much time before playback is started. Voila - instant protection against starvation due to silent frames being compressed to ultra-tiny packets with a long delay. Some of the comments here have talked about low latency, but I would say that low latency has no place in an internet streaming broadcast. I mean, the listened have no frame of reference for latency anyway, so what does it matter if the latency is really high? Now that I think about it this way, I'd say that FLAC and OggFLAC should not have any real problems due to compression of silent frames. Any place there is a problem should be blamed on bad streaming client / player code, not on the format itself. Brian Willoughby Sound Consulting ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Synchronizing a streaming client to the server Was: Idea to possibly improve flac?
There is a hack fix that won't break the standard. Disable constant subframes and fixed subframes on the encoding end. 100% compatible. Your going to be using all that bandwidth most of the time anyways, and when it goes down temporarily, that could actually cause a problem at the network level depending on the fancyness of your QoS and other routing razzle dazzle. Here is the other hack so that you don't get a logjam in the Ogg layer. https://github.com/oneman/libflac/commit/67e13364032404ebc1837af143fdd1cd81786c3a -David On Fri, Jan 7, 2011 at 9:12 PM, Brian Willoughby wrote: > > On Jan 7, 2011, at 16:48, Ben Allison wrote: >> The issue is that silent frames compress to a very small size, and >> the Ogg >> packeting layer can put more than one FLAC frame into a page. So >> if you >> have an extended period of silence with a live or rate-limited input >> stream, the client buffers may exhaust themselves before a new page >> can be >> put together and transmitted. > > Ah, yes, I remember reading about this. It does seem like an > unfortunate problem, and I would guess that both FLAC and OggFLAC > have the same issue. At the very least, I don't see how OggFLAC > could compress more than FLAC when using FLAC, and thus the problem > should be the same in both. > > However, if you've been following my suggestions about flagging > silence and other gaps in the broadcast content, then I think there > might be a common solution to both problems. With flags for silence > defined in the protocol, the streaming broadcast server would be able > to alert the clients to the situation where an extended period of > silence is about to occur. Maybe there would even need to be some > advance notice, otherwise the flags would come too late, just like > the silent frames. Seems like the streaming broadcast server could > define some sort of maximum time gap, and if a future frame is going > to exceed this maximum time, then a prior frame could be encoded with > a flag announcing the imminent "problem" - upon which the client > could simply prepare to go silent and resync. > > It still seems difficult, because the trailing audio right before the > silent frames could end up getting trapped in a FLAC block that takes > too long to arrive because it is mostly silent, but not completely > silent. Perhaps a "short" block is needed so that all of the non- > silent audio can be sent right away, along with a warning flag, and > then the client will know to produce silence (and perhaps resync) > until the super-compressed silent frames finally arrive. > > Unfortunately, this all seems like a significant deviation from the > FLAC streaming standard, unless variable block sizes can be allowed. > I must admit that I have not studied this closely, but I do seem to > recall that the block can is allowed to vary under certain > conditions. It might be the case that certain decoders only work > with fixed block sizes, but a streaming broadcast client would > obviously be a special case where support for small blocks could be > mandatory without causing a huge problem. > > Apparently, slim has something along these lines in their stream, but > I wonder whether they've fully taken advantage of the possibilities. > > Brian Willoughby > Sound Consulting > > ___ > Flac-dev mailing list > Flac-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/flac-dev > ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Synchronizing a streaming client to the server Was: Idea to possibly improve flac?
On Fri, Jan 7, 2011 at 7:36 PM, Brian Willoughby 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'll take credit for this, toot toot toot :D > > On Jan 7, 2011, at 15:04, David Richards wrote: >> >> I am interested in streaming lossless audio, FLAC is probably the best >> option for that. Currently the OggFLAC way of doing it mostly works >> with a few hacks in libflac and my version of edcast. It might be that >> the Ogg packaging layer is ill suited for this purpose, and an >> alternative model developed. I've seen that its possible to stream >> native flac with netcat, but thats not really the solution I'm looking >> for. > > I have not done much work with streaming. I have written a lot of serious > code that uses the FLAC library. I remember that there used to be separate > objects in the FLAC library for streams, and they were unique from the file > objects because you can seek backwards in a file, but you cannot seek > backwards in a stream. For some reason, it seems that these objects have > been removed in the latest versions of the FLAC library. > > Can anyone explain the issues with streaming pure FLAC? What does OggFLAC > add to make streaming possible, or even easier than pure FLAC? I thought > that OggFLAC was just a way to put FLAC blocks into the Ogg file format. > Apple's CAF specification would also allow FLAC blocks to be placed inside > their file container, although this still would not force iTunes to play > FLAC unless a decoder were installed in the system. > > What is it about netcat that you don't like? Can you describe what you're > looking for, and why the specific details are important? I was always under > the impression that the FLAC format was already designed for streaming, but > I must admit that I've never studied the issue. > > Ok dokie, basically libflac provides functions for working with streams as well as files, but thats as far as it goes and there is a bit more needed for a entire solution. So libflac is ready to go, but you need more that libflac to stream, in the same way that you need more than libflac to hear a flac being played... What I mean by this for those reading is that libflac provides functions for encoding and decoding from an arbitrary buffer rather than a file. netcat isn't right for what I think are obvious reasons, namely one to many transmission, it just doesn't scale in the correct way something like icecast and a vorbis stream would. I actually have never bothered to try it, but I think you actually have to hack libflac even for that because many programs that play flac will wait until the end of the silent (constant) subframes before continuing to decode so any silence gets you out of sync... Compatibility with icecast would really be the ideal way to handle it I think. I'm not sure how it might get in the way if your goal was super low latency, but I think it still may work in that case. OggFLAC currently works with icecast, thats why I started messing with it. It somewhat hijacks the Ogg part of the vorbis code in icecast from what I've seen.. I've been able to use it with about 1 second of latency just fine on localhost and other machines on my network. It doesn't support metadata updates, ie. chained ogg decoding, but I don't think any clients do either. I think wrote the only client that doesn't crash when listening to OggFLAC for extended periods too, lol. Mplayer will crash randomly, and VLC will stop and rebuffer randomly.. So in summary Icecast is a http 1.0 streaming music server, and if its oggflac getting fixed, native flac with perhaps some kind of small wrapper or modification, I think that should be a target protocol, everyone uses icecast. And if for some reason icecast doesn't suit the lowest latency situations, perhaps a small protocol could be designed to wrap native flac and provide network streaming, with a lib, and some sample senders/receivers. A problem with native flac and streaming IIRC is that you only get one metadata frame and thats at the beginning or end of the stream. I really don't think metadata et all such as coverart and all of this really needs to be fretted over, really all that is needed is a string or two, maybe 255chars each, one can be the title or currently playing information and the second one arbitrary, and something to handle this time sync stuff we have been talking about. Of course any of this should handle all capabilities of the flac format, ie streaming 8 channel 24bit/96khz audio. I've been doing two channel 24bit 44.1khz, and the bitrate is a bout 200-250K (thats big K) per second, I haven't tried 4 or 5 channel yet, but I intend to ( I will be building support into edcast2 for this). Also BTW if anyone has a link on some information about why 96khz is better than 48/44.1 id like to see it, because I don't comprehend why it would be. 24bit
Re: [Flac-dev] Idea to possibly improve flac?
> 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, most blokes, you know, will be playing at ten. You're on ten here, all the way up, all the way up, all the way up, you're on ten on your guitar. Where can you go from there? Where? " Oh well. - BW On Fri, Jan 7, 2011 at 9:08 PM, Declan Kelly wrote: > 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 > ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Synchronizing a streaming client to the server Was: Idea to possibly improve flac?
On Jan 7, 2011, at 16:48, Ben Allison wrote: > The issue is that silent frames compress to a very small size, and > the Ogg > packeting layer can put more than one FLAC frame into a page. So > if you > have an extended period of silence with a live or rate-limited input > stream, the client buffers may exhaust themselves before a new page > can be > put together and transmitted. Ah, yes, I remember reading about this. It does seem like an unfortunate problem, and I would guess that both FLAC and OggFLAC have the same issue. At the very least, I don't see how OggFLAC could compress more than FLAC when using FLAC, and thus the problem should be the same in both. However, if you've been following my suggestions about flagging silence and other gaps in the broadcast content, then I think there might be a common solution to both problems. With flags for silence defined in the protocol, the streaming broadcast server would be able to alert the clients to the situation where an extended period of silence is about to occur. Maybe there would even need to be some advance notice, otherwise the flags would come too late, just like the silent frames. Seems like the streaming broadcast server could define some sort of maximum time gap, and if a future frame is going to exceed this maximum time, then a prior frame could be encoded with a flag announcing the imminent "problem" - upon which the client could simply prepare to go silent and resync. It still seems difficult, because the trailing audio right before the silent frames could end up getting trapped in a FLAC block that takes too long to arrive because it is mostly silent, but not completely silent. Perhaps a "short" block is needed so that all of the non- silent audio can be sent right away, along with a warning flag, and then the client will know to produce silence (and perhaps resync) until the super-compressed silent frames finally arrive. Unfortunately, this all seems like a significant deviation from the FLAC streaming standard, unless variable block sizes can be allowed. I must admit that I have not studied this closely, but I do seem to recall that the block can is allowed to vary under certain conditions. It might be the case that certain decoders only work with fixed block sizes, but a streaming broadcast client would obviously be a special case where support for small blocks could be mandatory without causing a huge problem. Apparently, slim has something along these lines in their stream, but I wonder whether they've fully taken advantage of the possibilities. Brian Willoughby Sound Consulting ___ 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 Jan 7, 2011, at 16:27, Declan Kelly wrote: > 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. You may be right, but I actually suspect that it will be just as difficult to detect even just a single generation of MP3 encoding. Because lossy coding involves variable quantization in the frequency domain, that makes it rather difficult to predict a precise criterion for detection. > 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. If you're on OSX, then you can grab my free AudioUnit that implements RIAA decoding. It's called AURIAA, and is available at http:// www.sounds.wa.com/audiounits.html > 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. In this case, you have been misled by a common misconception in the consumer audio industry. In actuality, the human hearing system is quite capable of telling direction with lower frequencies, it's merely incompatible with studio mixing. At low frequencies, the human ear+brain system uses time delays to detect direction. This is because low frequencies travel around obstructions like the head without significant volume losses. Thus, it would be impossible to use volume to find the directional source. The brain then detects the leading edge of sounds, and compares the phase or time delay between left and right. When the direction is straight ahead, the time delay is zero. As sound sources move away from directly ahead, the time delay increases until a maximum determined by the speed of sound and the distance between your ears (plus a little extra for the path taken from one ear to the other is not through your head but around it, and that's a slightly longer time delay). However, as the frequency gets higher and higher, it becomes too difficult for the brain to analyze the phase differences, because a high frequency waveform will repeat several times during the time delay, and it become impossible to compare phase when you don't know which cycle matches. Fortunately, high frequencies are very directional - more directional than low frequencies - and thus the volume is attenuated when high frequency sounds bend around an obstruction (like the head or anything else). So, the brain uses volume differences, not time/phase differences, to determine directionality for high frequencies. What's true is that we humans are actually directionally deaf in the midrange, not at lower frequencies. The time/phase technique is most effective at the lowest frequencies, and becomes less effective as the frequency gets higher. The volume/amplitude technique is more effective at the highest frequencies, and becomes less effective as the frequency gets lower and less directional. In the middle, neither technique is effective. I seem to recall that this frequency is around 500 Hz, well below the 2 kHz to 5 kHz range where our ears are most sensitive. The reason why most consumer electronics experts get this wrong is because of the standard techniques use in studio recording. Most music is recorded as multiple channels, e.g., 16, that are each monophonic. These channels are played back through a mixing console, and a simple pan pot is used to artificially place them in a location. Because the pan pot only effects the volume, not the phase difference or time delay, this means that a studio recording is going to have no directionality at low frequencies. But not all recordings are made in a sound proof studio. A simple binaural recording will have plenty of time delay and phase information, just like the real world, and the human hearing system will easily be able to detect direction of low frequency sounds. That is, unless your audiophile salesman has convinced you that you only need one subwoofer, and thus your playback system is compromised. Another factor that is showing up in digital production is the ability to create a 3D mixer, instead of a simple pan pot. CoreAudio and other digital systems allow a monophonic sound to be placed at any position in a virtual 3D sound world, and the DSP will calculate the
Re: [Flac-dev] Synchronizing a streaming client to the server Was: Idea to possibly improve flac?
On Fri, Jan 7, 2011 at 8:29 PM, Brian Willoughby wrote: > Awesome! Can ya help a brotha' out and send some links to the slim > protocol? I suppose Google could find it for me, but if you're familiar > with the project then I'd appreciate an insider's pointers. alas, i got my copy of the source from a 3rd party that had already hacked it quite a bit to support a fairly high end playback device. my guess is that logitech's download/support section of their website would have it. but if you decide to look at it, stay away from the perl and stick with the C. > A friend has some old slim hardware, and I've been trying to help him with > converting files for playback, so I do have a little bit of experience with > the history. i'm not convinced that its necessarily the same kind of reset, since slim is not a broadcast server - each client has its own independent stream. but ... there is a way to sync multiple players, and that must involve some similar magic. --p ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Synchronizing a streaming client to the server Was: Idea to possibly improve flac?
On Jan 7, 2011, at 17:18, Paul Davis wrote: > On Fri, Jan 7, 2011 at 7:36 PM, Brian Willoughby > wrote: >> I'd like to borrow these ideas, or at >> least similarly-inspired ideas, and have FLAC streaming designed such >> that the stream can tell the playback software when to reset. > > the internals of the slim protocol does this. its all open source. i > was doing some work on this in 2009 to get it to handle multiple > sample rates, which it wasn't really designed for, but the "reset" > concept is all there. Awesome! Can ya help a brotha' out and send some links to the slim protocol? I suppose Google could find it for me, but if you're familiar with the project then I'd appreciate an insider's pointers. A friend has some old slim hardware, and I've been trying to help him with converting files for playback, so I do have a little bit of experience with the history. Brian Willoughby Sound Consulting ___ 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 Jan 7, 2011, at 15:54, Jørgen Vigdal wrote: > My first suggestion was to use FFT, because I know that 128kbps mp3 > have a low-pass filter at 16kHz (Fraunhofer IIS Encoder). The > program should not decide whether or not the file is a mp3 based on > only that, but it could give an indication on that. Perhaps with > people not very familiar with advanced audio tools know how to spot > out a mp3, they just want to know if the flac they just bought or > downloaded is good or not? What I have found is that audio above 15.8 kHz seems to come and go, probably based upon available bits. While some MP3 may have more of a constant state of nothing at those high frequencies, other MP3 bit rates will have intermittent content. What does seem to be true is that no version of MP3 or MP4/AAC will encode anything above 20 kHz. Even with the CD 44.1 kHz sample rate, there is still some possibilities for frequencies between 20 kHz and 22.05 kHz. Lossy encoding will never encode those frequencies. With either frequency range, though, you're going to have a slight problem detecting absence of frequency information. That's because lossy coding allows noise at all frequencies. So, your FFT is still going to show something above 15.8 kHz, and even something above 20 kHz, especially if the source was 16-bit instead of 24-bit. Thus, you'll need an intelligent threshold, and perhaps adaptive algorithms to detect lossy coding. It's quite normal for some acoustic recordings to have low levels of audio content at higher frequencies, especially if the microphone was located a long distance from the sound source, because of the high-frequency attenuation properties of air given sufficient distance. > Another test, if the FFT test is unclear, is to check the > correlation between left and right channel below 3kHz, which should > be just about nothing if the source is a mp3 (since mp3 encoders > sum L and R below 3kHz at low bitrates). If also doing further > testing, and knowing how the mp3 encoders work, it should be fairly > easy to determine if a source file might have been an mp3. At least > the program would be able to tell if the input file is poor > quality? :) Some encoders drop information below 10 Hz, some do not. I am not aware of mono coding for 3 kHz and below. Perhaps this depends upon whether the Joint Stereo option is being used or not. In any case, I would suggest that very common encoders might not have the properties you're describing. In any case, I don't want to discourage your efforts. I just think it might be harder than you think. For one thing, lossy coding doesn't really drop frequencies as described in most introductory texts, but rather what they really do is allow significant quantization noise to creep in at different frequencies. Thus, your 16-bit CD might be coded at 8-bit or less in some frequencies, where it might actually have the equivalent of 24-bit at other frequencies. Since you generally cannot recode lossy files without going back to the original, I expect this also means that you can't detect everything with an FFT, even if you're running the exact same FFT used by the lossy encoder. It should be a fun learning experience, though! Keep us posted with your findings! Brian Willoughby Sound Consulting ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Synchronizing a streaming client to the server Was: Idea to possibly improve flac?
On Fri, Jan 7, 2011 at 7:36 PM, Brian Willoughby wrote: > I'd like to borrow these ideas, or at > least similarly-inspired ideas, and have FLAC streaming designed such > that the stream can tell the playback software when to reset. the internals of the slim protocol does this. its all open source. i was doing some work on this in 2009 to get it to handle multiple sample rates, which it wasn't really designed for, but the "reset" concept is all there. ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Idea to possibly improve flac?
> The whole picture is a bit inconsistent. 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? Compression levels above 8 for Flake just don't conform to the 'subset' defined in FLAC, meaning that some implementations may not play them. They play fine on libFLAC-based players on desktop platforms, though. ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Indexed FLAC file?
On Fri, Jan 7, 2011 at 6:11 PM, Brian Waters wrote: > .m3u and .pls playlist files are pretty common and most major media > players support them, maybe even embedded ones like the one in your > car. David's right, the best thing is to make a database of your stuff > (iTunes was good, the last time I had a mac), but then that won't work > in your car or anything. > > For a long time I've wanted to make a web-based music database that > does the tables the right way, with foreign keys and lookup tables for > artists and albums, instead of the naieve "giant excel spreadsheet" > approach that everything else takes these days. For thirty bucks a > month you could stream your stuff to your smartphone and rock out > wherever there's a headphone jack. Actually, there is something like > that out now (but I thought of it first!), it's called subsonic, and I > haven't looked at it. If I ever stop being lazy and build my project, > I'll send you an email. a squeeze client for your phone and squeezeserver (now slimserver) on the machine with all the music will do this already. not sure who/want has done a squeeze/slim implementation for iOS or android, but it can't be hard - the source code for a client is all out there. ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Idea to possibly improve flac?
Lots of comments throughout this one... On Jan 7, 2011, at 15:28, Declan Kelly wrote: > On Fri, Jan 07, 2011 at 02:22:51PM -0800, bri...@sounds.wa.com wrote: >> 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. Very interesting. I've purchased many CD titles with reissued material where they clearly did not have access to anything but vinyl for some tracks. It was weird to hear the needle drop, with rumble throughout, especially since I has the original CD versions of the same tracks in my collection. Also, the early days of Warp Records involved many artists who sent in demoes on analog tape, and there is obvious wow and flutter on these tracks, especially at the beginning before the tape was properly tensioned. A while back, when HD audio was quite rare, I purchased some titles that were clearly low quality. Some 24/88.2 and 24/96 material had nothing but noise above 20 kHz, but the audio content was clearly from CD sources. I suppose the thought was that there was less noise in the audible range below 20 kHz. Certain "HD" titles were atrocious, with obvious indications that the source was 44.1 kHz and the upper frequencies were clearly nothing more than aliased frequencies! What's worse is that the aliased titles were samples on an HD audio site. They clearly didn't get my money. >> 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. I have also worked with mastering of a compilation CD including some material recorded and mixed on DCC. What's interesting in this one case is that the "music" was in the "noise" genre, and the DCC was used as an effect. It could not handle the content and therefore ending up changing it. 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. >> 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. 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? I have written software which can detect 16-bit audio samples stored in a 24-bit file format. Frequency analysis makes it obvious whether the content extends above 20 kHz. But I just want to make sure that there isn't another technique that I'm missing. >> 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. The whole picture is a bit inconsistent. 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? >> 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
Re: [Flac-dev] Synchronizing a streaming client to the server Was: Idea to possibly improve flac?
The issue is that silent frames compress to a very small size, and the Ogg packeting layer can put more than one FLAC frame into a page. So if you have an extended period of silence with a live or rate-limited input stream, the client buffers may exhaust themselves before a new page can be put together and transmitted. > 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. > > On Jan 7, 2011, at 15:04, David Richards wrote: >> I am interested in streaming lossless audio, FLAC is probably the best >> option for that. Currently the OggFLAC way of doing it mostly works >> with a few hacks in libflac and my version of edcast. It might be that >> the Ogg packaging layer is ill suited for this purpose, and an >> alternative model developed. I've seen that its possible to stream >> native flac with netcat, but thats not really the solution I'm looking >> for. > > I have not done much work with streaming. I have written a lot of > serious code that uses the FLAC library. I remember that there used > to be separate objects in the FLAC library for streams, and they were > unique from the file objects because you can seek backwards in a > file, but you cannot seek backwards in a stream. For some reason, it > seems that these objects have been removed in the latest versions of > the FLAC library. > > Can anyone explain the issues with streaming pure FLAC? What does > OggFLAC add to make streaming possible, or even easier than pure > FLAC? I thought that OggFLAC was just a way to put FLAC blocks into > the Ogg file format. Apple's CAF specification would also allow FLAC > blocks to be placed inside their file container, although this still > would not force iTunes to play FLAC unless a decoder were installed > in the system. > > What is it about netcat that you don't like? Can you describe what > you're looking for, and why the specific details are important? I > was always under the impression that the FLAC format was already > designed for streaming, but I must admit that I've never studied the > issue. > > >> On Fri, Jan 7, 2011 at 5:58 PM, Tor-Einar Jarnbjo > ei...@jarnbjo.name> wrote: >>> Am 07.01.2011 23:38, schrieb David Richards: I'm also interested in another concept of lossless streaming with flac. Lets call it broadcast flac. A problem with streaming for long periods of time is that the sending and receiving computers clocks go out of sync, for example even if I stream myself on localhost, with >>> >>> This is not a FLAC specific problem, but has to be handled in all >>> situations >>> where the streaming server is in control of the transmitting data >>> rate. It's >>> caused by a playback device, which actual sample rate is slightly >>> higher >>> than the sample rate actually requested or a streaming source, >>> which system >>> clock is running slowly. Since these parameters (at least an exact >>> playback >>> sample rate) is hard to achieve, this is a rather common problem. >>> Or to >>> shorten it: If the data has a sample rate of 44100 and your sound >>> card >>> consumes more than 44100 samples per "sender-time" second, your >>> buffer will >>> eventually exhaust. If it's the other way around, your buffer may >>> overflow >>> if the client does not handle these cases properly. >> >> I am well aware its not flac specific, but such a standard way of >> handling such a matter could be part of the packaging for streaming >> flac. > I think that this would be a good opportunity to design a solution > that is specific to broadcast. At the sending end, the server should > have knowledge of when there are breaks in the content. If the > stream could send flags at these breaks, then the receiving client > could go silent and reset the synchronization. As you describe, the > situation only becomes a problem after long periods of time, but I > would guess that there are enough station breaks (or at least song > breaks) in a long broadcast that there would be a chance for a reset. > > CoreAudio is a pull model, and the API provides a time line that can > be used to find the audio samples for a specific time. However, > there are many cases where this time line gets reset. Usually, each > callback has a time stamp that occurs precisely after the previous > callback. Obviously, the audio should not glitch when the time line > is contiguous, and thus the data must be sample-accurate. However, > CoreAudio code must also deal with situations where the time line > starts over from 0, usually under control of the host application. > CoreAudio also has a flag in the callback to indicate when the > buffers are totally silent. I'd like to borrow these ideas, or at > least similarly-inspired ideas, and have FLAC streaming designed such > that the stream can tell the playback software when to reset. > > The typical process to deal with synchronization of separate
Re: [Flac-dev] Synchronizing a streaming client to the server Was: Idea to possibly improve flac?
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. On Jan 7, 2011, at 15:04, David Richards wrote: > I am interested in streaming lossless audio, FLAC is probably the best > option for that. Currently the OggFLAC way of doing it mostly works > with a few hacks in libflac and my version of edcast. It might be that > the Ogg packaging layer is ill suited for this purpose, and an > alternative model developed. I've seen that its possible to stream > native flac with netcat, but thats not really the solution I'm looking > for. I have not done much work with streaming. I have written a lot of serious code that uses the FLAC library. I remember that there used to be separate objects in the FLAC library for streams, and they were unique from the file objects because you can seek backwards in a file, but you cannot seek backwards in a stream. For some reason, it seems that these objects have been removed in the latest versions of the FLAC library. Can anyone explain the issues with streaming pure FLAC? What does OggFLAC add to make streaming possible, or even easier than pure FLAC? I thought that OggFLAC was just a way to put FLAC blocks into the Ogg file format. Apple's CAF specification would also allow FLAC blocks to be placed inside their file container, although this still would not force iTunes to play FLAC unless a decoder were installed in the system. What is it about netcat that you don't like? Can you describe what you're looking for, and why the specific details are important? I was always under the impression that the FLAC format was already designed for streaming, but I must admit that I've never studied the issue. > On Fri, Jan 7, 2011 at 5:58 PM, Tor-Einar Jarnbjo ei...@jarnbjo.name> wrote: >> Am 07.01.2011 23:38, schrieb David Richards: >>> I'm also interested in another concept of lossless streaming with >>> flac. Lets call it broadcast flac. A problem with streaming for long >>> periods of time is that the sending and receiving computers >>> clocks go >>> out of sync, for example even if I stream myself on localhost, with >> >> This is not a FLAC specific problem, but has to be handled in all >> situations >> where the streaming server is in control of the transmitting data >> rate. It's >> caused by a playback device, which actual sample rate is slightly >> higher >> than the sample rate actually requested or a streaming source, >> which system >> clock is running slowly. Since these parameters (at least an exact >> playback >> sample rate) is hard to achieve, this is a rather common problem. >> Or to >> shorten it: If the data has a sample rate of 44100 and your sound >> card >> consumes more than 44100 samples per "sender-time" second, your >> buffer will >> eventually exhaust. If it's the other way around, your buffer may >> overflow >> if the client does not handle these cases properly. > > I am well aware its not flac specific, but such a standard way of > handling such a matter could be part of the packaging for streaming > flac. I think that this would be a good opportunity to design a solution that is specific to broadcast. At the sending end, the server should have knowledge of when there are breaks in the content. If the stream could send flags at these breaks, then the receiving client could go silent and reset the synchronization. As you describe, the situation only becomes a problem after long periods of time, but I would guess that there are enough station breaks (or at least song breaks) in a long broadcast that there would be a chance for a reset. CoreAudio is a pull model, and the API provides a time line that can be used to find the audio samples for a specific time. However, there are many cases where this time line gets reset. Usually, each callback has a time stamp that occurs precisely after the previous callback. Obviously, the audio should not glitch when the time line is contiguous, and thus the data must be sample-accurate. However, CoreAudio code must also deal with situations where the time line starts over from 0, usually under control of the host application. CoreAudio also has a flag in the callback to indicate when the buffers are totally silent. I'd like to borrow these ideas, or at least similarly-inspired ideas, and have FLAC streaming designed such that the stream can tell the playback software when to reset. The typical process to deal with synchronization of separate systems is sample rate conversion. However, this introduces distortion into the audio, especially with real-time SRC. The only way to avoid SRC is to have some way to reset the alignment without dropping or adding samples. As I said above, if the broadcast server were to put flags in the stream to indicate silent breaks in the audio, then the playb
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?
Cool, thanks for all the great comments. 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. My first suggestion was to use FFT, because I know that 128kbps mp3 have a low-pass filter at 16kHz (Fraunhofer IIS Encoder). The program should not decide whether or not the file is a mp3 based on only that, but it could give an indication on that. Perhaps with people not very familiar with advanced audio tools know how to spot out a mp3, they just want to know if the flac they just bought or downloaded is good or not? Another test, if the FFT test is unclear, is to check the correlation between left and right channel below 3kHz, which should be just about nothing if the source is a mp3 (since mp3 encoders sum L and R below 3kHz at low bitrates). If also doing further testing, and knowing how the mp3 encoders work, it should be fairly easy to determine if a source file might have been an mp3. At least the program would be able to tell if the input file is poor quality? :) J. On Jan 8, 2011, at 12:28 AM, Declan Kelly wrote: > 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. ___ 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
Re: [Flac-dev] Idea to possibly improve flac?
Of Course! It would be fun. I don't have too much time to spend, but I'll try my best to contribute to the project :) If anyone more interested, feel free to get in touch! J. On Jan 7, 2011, at 11:55 PM, Brian Waters wrote: > The scene is full of scumbag hackers who would have no trouble getting > around anything done on the encode side anyway. A better solution > would be a decoder that warns the user when there's a potential > transcode... of course, that's really not something that the FLAC > decoder should do. Could be a fun "third party" project for users who > care about that sort of thing. Plus, I'm pretty sure you can benefit > from doing an FFT on a GPU (even more fun!). > > Jørgen, you interested? I think you're right, it's not a very big > project at all. > > - Brian > ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Indexed FLAC file?
.m3u and .pls playlist files are pretty common and most major media players support them, maybe even embedded ones like the one in your car. David's right, the best thing is to make a database of your stuff (iTunes was good, the last time I had a mac), but then that won't work in your car or anything. For a long time I've wanted to make a web-based music database that does the tables the right way, with foreign keys and lookup tables for artists and albums, instead of the naieve "giant excel spreadsheet" approach that everything else takes these days. For thirty bucks a month you could stream your stuff to your smartphone and rock out wherever there's a headphone jack. Actually, there is something like that out now (but I thought of it first!), it's called subsonic, and I haven't looked at it. If I ever stop being lazy and build my project, I'll send you an email. - BW On Fri, Jan 7, 2011 at 5:53 PM, George Barton wrote: > Hi all, > I have a very large music collection that I keep on a portable hard > drive (to plug in to car USB, carry with when I'm at my office, etc). > All but a few dozen files are part of an album, and not a single audio > file. This translates to an insane amount of files stored on my hard > drive. I am very strict about how I label and file my media (I loathe > unlabeled audio tracks), but even so it is very tedious at times to > navigate this file structure, and takes a long time to load in my car. I > have seen other file formats (specifically one proprietary audio book > format) that supported indexing, and think it would be a great feature > to add to FLAC. Example... > > Instead of having: > \Dark Side of the Moon > 01 - Speak to Me.FLAC > 02 - Breathe.FLAC > 03 - On the Run.FLAC > ... > > Like a CD, you would have: > Dark Side of the Moon.FLAC > -01 - Speak to Me > -02 - Breathe > -03 - On the Run > ... > > It seems to me that a .cue (or something similar) file could be appended > to the FLAC file, and the ID tags modified and merged to reflect the > indexes. Any newer program/hardware could take full advantage of the > indexes, and any older program/hardware would simply see the FLAC file. > > I can see one major disadvantage. It would be more difficult to place a > full playlist in shuffle mode without the program/hardware creating a > master index detailing the contents of each file. However, many > computer-based media players already do this. > > I'm not very (any) good (at all) at coding, or I would have a go at > creating this. > > Just a thought... > ___ > Flac-dev mailing list > Flac-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/flac-dev > ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Idea to possibly improve flac?
I think it should just have an arm reach out of the computer monitor and hit them on the head with a bat. ( A nerf bat of course ) In all honesty, its only giving the codec a bad name to people who didn't bother to even learn about it for one second. Setting these kind of people strait is a lifes work for many a thinking man, but it is not my battle. -David On Fri, Jan 7, 2011 at 5:59 PM, Markus Ewald wrote: > On 1/7/2011 11:42 PM, Jørgen Vigdal wrote: >> Hi Brian. >> >> 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. Some groups (or even >> individuals) are releasing their stuff that is being "ripped off" another >> release, and they transcode the original release (mp3 320kbps for example) >> to a flac release (that really isn't a flac). >> >> 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, and >> also, as you mention in your answer, having fun and experimenting with the >> flac code. >> > ... 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? > > 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. > >> Thanks, >> >> J. > -Markus- > > ___ > Flac-dev mailing list > Flac-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/flac-dev > ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Synchronizing a streaming client to the server Was: Idea to possibly improve flac?
On Fri, Jan 7, 2011 at 5:58 PM, Tor-Einar Jarnbjo wrote: > Am 07.01.2011 23:38, schrieb David Richards: >> >> I'm also interested in another concept of lossless streaming with >> flac. Lets call it broadcast flac. A problem with streaming for long >> periods of time is that the sending and receiving computers clocks go >> out of sync, for example even if I stream myself on localhost, with > > This is not a FLAC specific problem, but has to be handled in all situations > where the streaming server is in control of the transmitting data rate. It's > caused by a playback device, which actual sample rate is slightly higher > than the sample rate actually requested or a streaming source, which system > clock is running slowly. Since these parameters (at least an exact playback > sample rate) is hard to achieve, this is a rather common problem. Or to > shorten it: If the data has a sample rate of 44100 and your sound card > consumes more than 44100 samples per "sender-time" second, your buffer will > eventually exhaust. If it's the other way around, your buffer may overflow > if the client does not handle these cases properly. > I am well aware its not flac specific, but such a standard way of handling such a matter could be part of the packaging for streaming flac. >> Anyway what could happen is the client could do a little bit of >> re-sampling here or there to ensure its in sync with the servers >> clock. > > That is how streaming clients usually solve this problem, although is not > really improving sound quality. Its probably not a big deal if you don't resample all the time, just when your off by X amount, all of this would just be client side preferences. As long as the client side "knows" its off by X amount you could handle it in any number of ways, I'd be fine if its just crossfaded to the correct timing if was off by more than half a second, then no resampling would ever happen, you would just get a weird effect about once an hour, better than a buffer underrun or lag, or perhaps the client could look for a half second of silence and just cut it out. -David > > Tor > > > ___ 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 1/7/2011 11:42 PM, Jørgen Vigdal wrote: > Hi Brian. > > 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. Some groups (or even > individuals) are releasing their stuff that is being "ripped off" another > release, and they transcode the original release (mp3 320kbps for example) to > a flac release (that really isn't a flac). > > 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, and > also, as you mention in your answer, having fun and experimenting with the > flac code. > ... 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? 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. > Thanks, > > J. -Markus- ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[Flac-dev] Synchronizing a streaming client to the server Was: Idea to possibly improve flac?
Am 07.01.2011 23:38, schrieb David Richards: > I'm also interested in another concept of lossless streaming with > flac. Lets call it broadcast flac. A problem with streaming for long > periods of time is that the sending and receiving computers clocks go > out of sync, for example even if I stream myself on localhost, with This is not a FLAC specific problem, but has to be handled in all situations where the streaming server is in control of the transmitting data rate. It's caused by a playback device, which actual sample rate is slightly higher than the sample rate actually requested or a streaming source, which system clock is running slowly. Since these parameters (at least an exact playback sample rate) is hard to achieve, this is a rather common problem. Or to shorten it: If the data has a sample rate of 44100 and your sound card consumes more than 44100 samples per "sender-time" second, your buffer will eventually exhaust. If it's the other way around, your buffer may overflow if the client does not handle these cases properly. > Anyway what could happen is the client could do a little bit of > re-sampling here or there to ensure its in sync with the servers > clock. That is how streaming clients usually solve this problem, although is not really improving sound quality. Tor ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Indexed FLAC file?
Probably what you want is a media player software that turns your file structure into a database, you won't have to spend so much time dealing with the tedium aspects of navigating the structure that way... However, I believe you could create such a file with MKV which can hold multiple tracks of flac AFAIK. I'd be curious to hear back if you try that specifically. Probably no normal music player will deal with mkv, but if your this into it you could develop your own.. ( if you wanted to look into a custom media player for option number one, take a look at xmms2 ) -David On Fri, Jan 7, 2011 at 5:53 PM, George Barton wrote: > Hi all, > I have a very large music collection that I keep on a portable hard > drive (to plug in to car USB, carry with when I'm at my office, etc). > All but a few dozen files are part of an album, and not a single audio > file. This translates to an insane amount of files stored on my hard > drive. I am very strict about how I label and file my media (I loathe > unlabeled audio tracks), but even so it is very tedious at times to > navigate this file structure, and takes a long time to load in my car. I > have seen other file formats (specifically one proprietary audio book > format) that supported indexing, and think it would be a great feature > to add to FLAC. Example... > > Instead of having: > \Dark Side of the Moon > 01 - Speak to Me.FLAC > 02 - Breathe.FLAC > 03 - On the Run.FLAC > ... > > Like a CD, you would have: > Dark Side of the Moon.FLAC > -01 - Speak to Me > -02 - Breathe > -03 - On the Run > ... > > It seems to me that a .cue (or something similar) file could be appended > to the FLAC file, and the ID tags modified and merged to reflect the > indexes. Any newer program/hardware could take full advantage of the > indexes, and any older program/hardware would simply see the FLAC file. > > I can see one major disadvantage. It would be more difficult to place a > full playlist in shuffle mode without the program/hardware creating a > master index detailing the contents of each file. However, many > computer-based media players already do this. > > I'm not very (any) good (at all) at coding, or I would have a go at > creating this. > > Just a thought... > ___ > Flac-dev mailing list > Flac-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/flac-dev > ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[Flac-dev] Indexed FLAC file?
Hi all, I have a very large music collection that I keep on a portable hard drive (to plug in to car USB, carry with when I'm at my office, etc). All but a few dozen files are part of an album, and not a single audio file. This translates to an insane amount of files stored on my hard drive. I am very strict about how I label and file my media (I loathe unlabeled audio tracks), but even so it is very tedious at times to navigate this file structure, and takes a long time to load in my car. I have seen other file formats (specifically one proprietary audio book format) that supported indexing, and think it would be a great feature to add to FLAC. Example... Instead of having: \Dark Side of the Moon 01 - Speak to Me.FLAC 02 - Breathe.FLAC 03 - On the Run.FLAC ... Like a CD, you would have: Dark Side of the Moon.FLAC -01 - Speak to Me -02 - Breathe -03 - On the Run ... It seems to me that a .cue (or something similar) file could be appended to the FLAC file, and the ID tags modified and merged to reflect the indexes. Any newer program/hardware could take full advantage of the indexes, and any older program/hardware would simply see the FLAC file. I can see one major disadvantage. It would be more difficult to place a full playlist in shuffle mode without the program/hardware creating a master index detailing the contents of each file. However, many computer-based media players already do this. I'm not very (any) good (at all) at coding, or I would have a go at creating this. Just a thought... ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Idea to possibly improve flac?
Hi Brian. 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. Some groups (or even individuals) are releasing their stuff that is being "ripped off" another release, and they transcode the original release (mp3 320kbps for example) to a flac release (that really isn't a flac). 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, and also, as you mention in your answer, having fun and experimenting with the flac code. Thanks, J. On Jan 7, 2011, at 11:22 PM, Brian Willoughby wrote: > First of all, I am not aware of any official source of FLAC files > that provide MP3 sourced data. I meticulously check the music I > purchase, especially when it is 24/48 or 24/96 material, because this > is new technology, and sometimes people get it wrong. > > 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 purchased a second release of an old download from > an artist who has his material re-mastered. Since he made such a big > deal about the re-mastering, I took a close look at the quality. For > some reason, the second track looked like an MP3 source, but I'm sure > it just has to do with the software that was used to create the music > originally. > > 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 purchase a great deal of music, exclusively in FLAC format. I > purchase from LINN Records, Bleep.com, Warp Records, and also > directly from artists like Nine Inch Nails who provide FLAC files. I > have never seen anyone provide MP3 quality. > > For that matter, OggFLAC seems to be a format that has never been > used. Ever. I have simply never come across a legitimate source of > music for purchasing which used the OggFLAC format. I have seen FLAC > come and go and come back again. > > Various online record labels started out with FLAC for bandwidth > reasons. Then they seemed to switch over to WAV as bandwidth became > less of an issue, and I assume that their customers were confused by > FLAC because of the lack of support in iTunes and other highly > popular players. Meanwhile, hardware such as the Sound Devices 700 > Series, the Squeezebox, and many other professional products has > started with FLAC and stuck with it. The sites who switched to WAV > are now bringing back FLAC, but none of them have ever used OggFLAC. > > Finally, I think that people who are not embedded firmware developers > do not understand why the FLAC sources have stopped changing. What > we have here is a rare case of a professional set of sources which do > not have bugs, and which represents a solid standard that does not > need changing. 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. > > Even when Apple came out with ALAC, their version of FLAC, I noticed > that they could not consistently beat FLAC on coding speed and file > size. Some audio turns out smaller with ALAC, other audio turns out > smaller with FLAC. Overall, the average performance is identical. > Apple hired some of the most amazing geniuses of physics to design > ALAC, and if they can't beat the performance of FLAC in all > situations, then what makes you think there is any reason to make a > single change to the FLAC sources? > > While I'm writing, I also want to respond to the question about how > to change FLAC so that all of the third party tools pick up the > change. Well, I don't think that is possible. Many tools run the > command-line flac utility behind the scenes. Others use the FLAC > library directly. The problem is that both of them often run with > out of date versions of the FLAC code, so no matter which way they > incorporate the official FLAC sources, you cannot make them update to > your anti-MP3 version. > > On that last note, I want to encourage you to experiment and have fun > trying to create an MP3 detector that could warn users about quality > issues. However, I believe it is extremely unlikely that you would > ever be successful in getting your code into the official FLAC > sources. This kind of change has nothing to do with the official > FLAC format, and thus I doubt there would be any professional > interes
Re: [Flac-dev] Idea to possibly improve flac?
I for one am not worried about getting mp3 encoded stuff in my flac files, but I want to respond about "legitimate" OggFLAC. OggFLAC as a format for files, I agree, used by no one. However, I don't know of any other open source way to stream lossless audio. Maybe I did not look hard enough. Certainly nothing I can think of that would hope to be compatible with standard media player softwares out there. I am interested in streaming lossless audio, FLAC is probably the best option for that. Currently the OggFLAC way of doing it mostly works with a few hacks in libflac and my version of edcast. It might be that the Ogg packaging layer is ill suited for this purpose, and an alternative model developed. I've seen that its possible to stream native flac with netcat, but thats not really the solution I'm looking for. I'm also interested in another concept of lossless streaming with flac. Lets call it broadcast flac. A problem with streaming for long periods of time is that the sending and receiving computers clocks go out of sync, for example even if I stream myself on localhost, with something like 1 second of buffertime, the client will eat into that over about one hour and run out of buffer causing a skip. It could also theoretically keep getting more and more lagged until its way behind. I'd like to develop a standard system that could be sent between the server and client side to keep there clients in sync to a fairly exacting amount of lag time behind the server (say 1.5 seconds, I think you end up with about a half second of delay with flac encoding no matter what but my brain is blanking on this right now, meaning it would not be suitable for 'real time" remote sound mixing). Anyway what could happen is the client could do a little bit of re-sampling here or there to ensure its in sync with the servers clock. If anyone is interested in such things, or knows of an existing system that I don't know of, give me a hollar! -David On Fri, Jan 7, 2011 at 5:22 PM, Brian Willoughby wrote: > First of all, I am not aware of any official source of FLAC files that > provide MP3 sourced data. I meticulously check the music I purchase, > especially when it is 24/48 or 24/96 material, because this is new > technology, and sometimes people get it wrong. > > 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 > purchased a second release of an old download from an artist who has his > material re-mastered. Since he made such a big deal about the re-mastering, > I took a close look at the quality. For some reason, the second track > looked like an MP3 source, but I'm sure it just has to do with the software > that was used to create the music originally. > > 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 purchase a great deal of music, exclusively in FLAC format. I purchase > from LINN Records, Bleep.com, Warp Records, and also directly from artists > like Nine Inch Nails who provide FLAC files. I have never seen anyone > provide MP3 quality. > > For that matter, OggFLAC seems to be a format that has never been used. > Ever. I have simply never come across a legitimate source of music for > purchasing which used the OggFLAC format. I have seen FLAC come and go and > come back again. > > Various online record labels started out with FLAC for bandwidth reasons. > Then they seemed to switch over to WAV as bandwidth became less of an > issue, and I assume that their customers were confused by FLAC because of > the lack of support in iTunes and other highly popular players. Meanwhile, > hardware such as the Sound Devices 700 Series, the Squeezebox, and many > other professional products has started with FLAC and stuck with it. The > sites who switched to WAV are now bringing back FLAC, but none of them have > ever used OggFLAC. > > Finally, I think that people who are not embedded firmware developers do not > understand why the FLAC sources have stopped changing. What we have here is > a rare case of a professional set of sources which do not have bugs, and > which represents a solid standard that does not need changing. 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. > > Even when Apple came out with ALAC, their version of FLAC, I noticed that > they could not consistently beat FLAC on coding speed and file size. Some > audio turns out smaller with ALAC, other audio turns out smaller with FLAC. > Overall, the average performance is identical. Apple hired some of the > most amazing geniuses of physics to design ALAC, and if they can't beat the > performance of FLAC in all situations, then what makes
Re: [Flac-dev] Idea to possibly improve flac?
I actually agree with pretty much everything Brian just said. To add to that though, I'd say that mp3-to-FLAC transcodes are a very real problem for, shall we say, illegitimate sources of material. (And that is a totally legitimate thing, in and of itself... er, what?) - BW On Fri, Jan 7, 2011 at 5:22 PM, Brian Willoughby wrote: > First of all, I am not aware of any official source of FLAC files > that provide MP3 sourced data. I meticulously check the music I > purchase, especially when it is 24/48 or 24/96 material, because this > is new technology, and sometimes people get it wrong. > > 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 purchased a second release of an old download from > an artist who has his material re-mastered. Since he made such a big > deal about the re-mastering, I took a close look at the quality. For > some reason, the second track looked like an MP3 source, but I'm sure > it just has to do with the software that was used to create the music > originally. > > 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 purchase a great deal of music, exclusively in FLAC format. I > purchase from LINN Records, Bleep.com, Warp Records, and also > directly from artists like Nine Inch Nails who provide FLAC files. I > have never seen anyone provide MP3 quality. > > For that matter, OggFLAC seems to be a format that has never been > used. Ever. I have simply never come across a legitimate source of > music for purchasing which used the OggFLAC format. I have seen FLAC > come and go and come back again. > > Various online record labels started out with FLAC for bandwidth > reasons. Then they seemed to switch over to WAV as bandwidth became > less of an issue, and I assume that their customers were confused by > FLAC because of the lack of support in iTunes and other highly > popular players. Meanwhile, hardware such as the Sound Devices 700 > Series, the Squeezebox, and many other professional products has > started with FLAC and stuck with it. The sites who switched to WAV > are now bringing back FLAC, but none of them have ever used OggFLAC. > > Finally, I think that people who are not embedded firmware developers > do not understand why the FLAC sources have stopped changing. What > we have here is a rare case of a professional set of sources which do > not have bugs, and which represents a solid standard that does not > need changing. 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. > > Even when Apple came out with ALAC, their version of FLAC, I noticed > that they could not consistently beat FLAC on coding speed and file > size. Some audio turns out smaller with ALAC, other audio turns out > smaller with FLAC. Overall, the average performance is identical. > Apple hired some of the most amazing geniuses of physics to design > ALAC, and if they can't beat the performance of FLAC in all > situations, then what makes you think there is any reason to make a > single change to the FLAC sources? > > While I'm writing, I also want to respond to the question about how > to change FLAC so that all of the third party tools pick up the > change. Well, I don't think that is possible. Many tools run the > command-line flac utility behind the scenes. Others use the FLAC > library directly. The problem is that both of them often run with > out of date versions of the FLAC code, so no matter which way they > incorporate the official FLAC sources, you cannot make them update to > your anti-MP3 version. > > On that last note, I want to encourage you to experiment and have fun > trying to create an MP3 detector that could warn users about quality > issues. However, I believe it is extremely unlikely that you would > ever be successful in getting your code into the official FLAC > sources. This kind of change has nothing to do with the official > FLAC format, and thus I doubt there would be any professional > interest in changing things just for the sake of change or "newness." > > Brian Willoughby > Sound Consultinf > > > On Jan 7, 2011, at 12:56, David Richards wrote: >> Its really sad to hear thats happening but even more sad is the fact >> that flac is becoming a very common format for music on the interweb >> whilst at the same time the development has ceased. I've found some >> severe issues with OggFLAC that essentially make it a useless format >> for streaming, no one cared. >> >> On Fri, Jan 7, 2011 at 3:42 PM, Jørgen Vigdal wrote: >>> Due to the fact that more and more users increasingly use MP3 < >>> 320kbps as >>> their source for encoding music, and publish it as f
Re: [Flac-dev] Idea to possibly improve flac?
First of all, I am not aware of any official source of FLAC files that provide MP3 sourced data. I meticulously check the music I purchase, especially when it is 24/48 or 24/96 material, because this is new technology, and sometimes people get it wrong. 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 purchased a second release of an old download from an artist who has his material re-mastered. Since he made such a big deal about the re-mastering, I took a close look at the quality. For some reason, the second track looked like an MP3 source, but I'm sure it just has to do with the software that was used to create the music originally. 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 purchase a great deal of music, exclusively in FLAC format. I purchase from LINN Records, Bleep.com, Warp Records, and also directly from artists like Nine Inch Nails who provide FLAC files. I have never seen anyone provide MP3 quality. For that matter, OggFLAC seems to be a format that has never been used. Ever. I have simply never come across a legitimate source of music for purchasing which used the OggFLAC format. I have seen FLAC come and go and come back again. Various online record labels started out with FLAC for bandwidth reasons. Then they seemed to switch over to WAV as bandwidth became less of an issue, and I assume that their customers were confused by FLAC because of the lack of support in iTunes and other highly popular players. Meanwhile, hardware such as the Sound Devices 700 Series, the Squeezebox, and many other professional products has started with FLAC and stuck with it. The sites who switched to WAV are now bringing back FLAC, but none of them have ever used OggFLAC. Finally, I think that people who are not embedded firmware developers do not understand why the FLAC sources have stopped changing. What we have here is a rare case of a professional set of sources which do not have bugs, and which represents a solid standard that does not need changing. 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. Even when Apple came out with ALAC, their version of FLAC, I noticed that they could not consistently beat FLAC on coding speed and file size. Some audio turns out smaller with ALAC, other audio turns out smaller with FLAC. Overall, the average performance is identical. Apple hired some of the most amazing geniuses of physics to design ALAC, and if they can't beat the performance of FLAC in all situations, then what makes you think there is any reason to make a single change to the FLAC sources? While I'm writing, I also want to respond to the question about how to change FLAC so that all of the third party tools pick up the change. Well, I don't think that is possible. Many tools run the command-line flac utility behind the scenes. Others use the FLAC library directly. The problem is that both of them often run with out of date versions of the FLAC code, so no matter which way they incorporate the official FLAC sources, you cannot make them update to your anti-MP3 version. On that last note, I want to encourage you to experiment and have fun trying to create an MP3 detector that could warn users about quality issues. However, I believe it is extremely unlikely that you would ever be successful in getting your code into the official FLAC sources. This kind of change has nothing to do with the official FLAC format, and thus I doubt there would be any professional interest in changing things just for the sake of change or "newness." Brian Willoughby Sound Consultinf On Jan 7, 2011, at 12:56, David Richards wrote: > Its really sad to hear thats happening but even more sad is the fact > that flac is becoming a very common format for music on the interweb > whilst at the same time the development has ceased. I've found some > severe issues with OggFLAC that essentially make it a useless format > for streaming, no one cared. > > On Fri, Jan 7, 2011 at 3:42 PM, Jørgen Vigdal wrote: >> Due to the fact that more and more users increasingly use MP3 < >> 320kbps as >> their source for encoding music, and publish it as flac files, I >> suggest >> that something is done in the flac encoder to possible avoid this. >> My idea is kinda easy/stupid, but might work; >> Implement a function that use a FFT to check if the input has >> frequencies > >> 16kHz, and informs the user that the file would not be encoded >> unless a >> -force parameter is specified (or at least ask the user if he or >>
Re: [Flac-dev] Idea to possibly improve flac?
No offense taken. I think... first party: you second party: libflac third party: gstreaemer or mplayer or something like that ... I think... PS David that looks cool - BW On Fri, Jan 7, 2011 at 4:34 PM, Jørgen Vigdal wrote: > Cool, thanks David. > > I'll have a look at it. > > - Jørgen. > > On Jan 7, 2011, at 10:29 PM, David Richards wrote: > >> I'd like to express a few things whilst I have the ear atleast a few folks. >> >> There once was a program called oddcast, and then edcast that you >> could use on linux to broadcast an OggFLAC encoded audio stream from >> jack. Sounds like something many folks would be interested in doing, >> but I haven't heard to much of a peep about it. At any rate, it had a >> a few issues legally and technical problems broadcasting an OggFLAC >> stream ( again related to periods of silence in the stream). So edcast >> is officialy dead now. >> >> But now it is an undead zombie! I talked to the original developer ( >> Ed ), then removed the legally questionable parts (and windows >> support), and fixed some issues with vorbis and oggflac encoding, and >> I even added support for 24bit flac. I'm probably the only guy in the >> universe listening to streaming 24bit audio, but if anyone wants to >> join me the code is located here: >> https://github.com/oneman/edcast2_jack >> >> Cheers, >> >> -D > > ___ > Flac-dev mailing list > Flac-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/flac-dev > ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Idea to possibly improve flac?
Cool, thanks David. I'll have a look at it. - Jørgen. On Jan 7, 2011, at 10:29 PM, David Richards wrote: > I'd like to express a few things whilst I have the ear atleast a few folks. > > There once was a program called oddcast, and then edcast that you > could use on linux to broadcast an OggFLAC encoded audio stream from > jack. Sounds like something many folks would be interested in doing, > but I haven't heard to much of a peep about it. At any rate, it had a > a few issues legally and technical problems broadcasting an OggFLAC > stream ( again related to periods of silence in the stream). So edcast > is officialy dead now. > > But now it is an undead zombie! I talked to the original developer ( > Ed ), then removed the legally questionable parts (and windows > support), and fixed some issues with vorbis and oggflac encoding, and > I even added support for 24bit flac. I'm probably the only guy in the > universe listening to streaming 24bit audio, but if anyone wants to > join me the code is located here: > https://github.com/oneman/edcast2_jack > > Cheers, > > -D ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Idea to possibly improve flac?
haha. Sorry, I actually did not mean to offend you, but I see now that I did :) If you study main.c in flac/ -you'd probably be best off to start there. Perhaps one of the more experienced developers knows where it should be inserted, in order to be included in the library being used by third-party apps. - Jørgen PS: One complete different thing; does anyone know why it is called "third-party" apps? Why third? On Jan 7, 2011, at 10:23 PM, Brian Waters wrote: >> It might be stupid, but I guess a good place to start would be in the main() >> function, where the program receives its parameters from the command line? > > Haha, touche. I'll do that. This probably fits better in the > command-line program than in the library, but then other programs that > use the library won't pick up the feature... > > - Brian > ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Idea to possibly improve flac?
I'd like to express a few things whilst I have the ear atleast a few folks. There once was a program called oddcast, and then edcast that you could use on linux to broadcast an OggFLAC encoded audio stream from jack. Sounds like something many folks would be interested in doing, but I haven't heard to much of a peep about it. At any rate, it had a a few issues legally and technical problems broadcasting an OggFLAC stream ( again related to periods of silence in the stream). So edcast is officialy dead now. But now it is an undead zombie! I talked to the original developer ( Ed ), then removed the legally questionable parts (and windows support), and fixed some issues with vorbis and oggflac encoding, and I even added support for 24bit flac. I'm probably the only guy in the universe listening to streaming 24bit audio, but if anyone wants to join me the code is located here: https://github.com/oneman/edcast2_jack Cheers, -D On Fri, Jan 7, 2011 at 4:19 PM, David Richards wrote: > I might be able to look into this soon, I actually got my mother a > squeezebox boom for xmas, but I have no experience with the device, > other than initial set up and hearing it go. My choice of the word > "useless" was deliberate to get folks rawled up, and it worked! :D It > doesn't make it entirely useless, just unreliable and inconsistent. If > they are using the code from the main flac branch unmodified then I'm > sure the device is hitting these bugs. There is different bugs in the > encoding and decoding side of things, and also in the ogg packaging > layer. All of this is related to periods of silence in the stream of > sound. > > -D > > On Fri, Jan 7, 2011 at 4:01 PM, Paul Davis wrote: >> On Fri, Jan 7, 2011 at 3:56 PM, David Richards wrote: >>> Its really sad to hear thats happening but even more sad is the fact >>> that flac is becoming a very common format for music on the interweb >>> whilst at the same time the development has ceased. I've found some >>> severe issues with OggFLAC that essentially make it a useless format >>> for streaming, no one cared. >> >> could have fooled slimdevices/logitech, which sends FLAC to all their boxes. >> > ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Idea to possibly improve flac?
Arg. This mailing list needs a reply-to header... Sent this to Jørgen: > It might be stupid, but I guess a good place to start would be in the main() > function, where the program receives its parameters from the command line? Haha, touche. I'll do that. This probably fits better in the command-line program than in the library, but then other programs that use the library won't pick up the feature... - Brian On Fri, Jan 7, 2011 at 4:18 PM, Jørgen Vigdal wrote: > I have not studied the flac codebase, but I'll do some research and try to > help you out. > > It might be stupid, but I guess a good place to start would be in the main() > function, where the program receives its parameters from the command line? > > - Jørgen > > On Jan 7, 2011, at 10:15 PM, Brian Waters wrote: > >> I'm busy 'till Monday morning but I'll break out the ole' diffy-q's >> textbook next week and do some background reading, thanks. Any clues >> on where in the code to look in order to put those hooks in? >> >> - Brian >> > > ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Idea to possibly improve flac?
I might be able to look into this soon, I actually got my mother a squeezebox boom for xmas, but I have no experience with the device, other than initial set up and hearing it go. My choice of the word "useless" was deliberate to get folks rawled up, and it worked! :D It doesn't make it entirely useless, just unreliable and inconsistent. If they are using the code from the main flac branch unmodified then I'm sure the device is hitting these bugs. There is different bugs in the encoding and decoding side of things, and also in the ogg packaging layer. All of this is related to periods of silence in the stream of sound. -D On Fri, Jan 7, 2011 at 4:01 PM, Paul Davis wrote: > On Fri, Jan 7, 2011 at 3:56 PM, David Richards wrote: >> Its really sad to hear thats happening but even more sad is the fact >> that flac is becoming a very common format for music on the interweb >> whilst at the same time the development has ceased. I've found some >> severe issues with OggFLAC that essentially make it a useless format >> for streaming, no one cared. > > could have fooled slimdevices/logitech, which sends FLAC to all their boxes. > ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Idea to possibly improve flac?
I have not studied the flac codebase, but I'll do some research and try to help you out. It might be stupid, but I guess a good place to start would be in the main() function, where the program receives its parameters from the command line? - Jørgen On Jan 7, 2011, at 10:15 PM, Brian Waters wrote: > I'm busy 'till Monday morning but I'll break out the ole' diffy-q's > textbook next week and do some background reading, thanks. Any clues > on where in the code to look in order to put those hooks in? > > - Brian > ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Idea to possibly improve flac?
I'm busy 'till Monday morning but I'll break out the ole' diffy-q's textbook next week and do some background reading, thanks. Any clues on where in the code to look in order to put those hooks in? - Brian On Fri, Jan 7, 2011 at 4:08 PM, Jørgen Vigdal wrote: > Hi Brian. > > Thanks for liking the idea. > > The code for doing this, could actually be fairly easy. If you start > researching on what a Fast Fourier Transform (FFT) is, and understand how to > implement a rough algorithm on this, you could easily add a test in the code, > before the encoder kicks in, and prompt a message to the user, that it should > be aware that the file could not be compressed, because it might already have > been compressed. > > If you need help implementing a FFT, I'd be happy to help out. > > I think the codebase is frozen because the development have ceased? > > - Jørgen. > > On Jan 7, 2011, at 10:03 PM, Brian Waters wrote: > >> I like this idea. I've been looking for an open source project to get >> my feet wet with. I'd love to work on the FLAC library, but I don't >> know jack s**t about compression algorithms, and I've never worked on >> a large project before. >> >> If someone would help guide me in the right direction, I'd love to do >> some of that code. >> >> - Brian Waters >> >> PS, whats the deal with the codebase being frozen? > > ___ 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 7, 2011 at 3:56 PM, David Richards wrote: > Its really sad to hear thats happening but even more sad is the fact > that flac is becoming a very common format for music on the interweb > whilst at the same time the development has ceased. I've found some > severe issues with OggFLAC that essentially make it a useless format > for streaming, no one cared. could have fooled slimdevices/logitech, which sends FLAC to all their boxes. ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Idea to possibly improve flac?
Hi Brian. Thanks for liking the idea. The code for doing this, could actually be fairly easy. If you start researching on what a Fast Fourier Transform (FFT) is, and understand how to implement a rough algorithm on this, you could easily add a test in the code, before the encoder kicks in, and prompt a message to the user, that it should be aware that the file could not be compressed, because it might already have been compressed. If you need help implementing a FFT, I'd be happy to help out. I think the codebase is frozen because the development have ceased? - Jørgen. On Jan 7, 2011, at 10:03 PM, Brian Waters wrote: > I like this idea. I've been looking for an open source project to get > my feet wet with. I'd love to work on the FLAC library, but I don't > know jack s**t about compression algorithms, and I've never worked on > a large project before. > > If someone would help guide me in the right direction, I'd love to do > some of that code. > > - Brian Waters > > PS, whats the deal with the codebase being frozen? ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Idea to possibly improve flac?
I like this idea. I've been looking for an open source project to get my feet wet with. I'd love to work on the FLAC library, but I don't know jack s**t about compression algorithms, and I've never worked on a large project before. If someone would help guide me in the right direction, I'd love to do some of that code. - Brian Waters PS, whats the deal with the codebase being frozen? On Fri, Jan 7, 2011 at 3:42 PM, Jørgen Vigdal wrote: > Hi folks! > Due to the fact that more and more users increasingly use MP3 < 320kbps as > their source for encoding music, and publish it as flac files, I suggest > that something is done in the flac encoder to possible avoid this. > My idea is kinda easy/stupid, but might work; > Implement a function that use a FFT to check if the input has frequencies > > 16kHz, and informs the user that the file would not be encoded unless a > -force parameter is specified (or at least ask the user if he or she want to > do this :) ) > Hopefully, this will reduce the number of files released on the internet, > re-encoded from a lossy file format. Unfortunately, many users avoid using > flac, because they think the encoder is lossy due to the poor sound on some > files released. > Thanks in advance. > Sincerely, > Jørgen Vigdal > jor...@anion.no > Phone: +47 91320132 > jorgenvigdal.com > ___ > Flac-dev mailing list > Flac-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/flac-dev > > ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Idea to possibly improve flac?
Yes, that was even more sad. Do you know if any of the developers wishes to continue the project? - Jørgen. On Jan 7, 2011, at 9:56 PM, David Richards wrote: > Its really sad to hear thats happening but even more sad is the fact > that flac is becoming a very common format for music on the interweb > whilst at the same time the development has ceased. I've found some > severe issues with OggFLAC that essentially make it a useless format > for streaming, no one cared. > > -David > Listener of many flacs > > > > On Fri, Jan 7, 2011 at 3:42 PM, Jørgen Vigdal wrote: >> Hi folks! >> Due to the fact that more and more users increasingly use MP3 < 320kbps as >> their source for encoding music, and publish it as flac files, I suggest >> that something is done in the flac encoder to possible avoid this. >> My idea is kinda easy/stupid, but might work; >> Implement a function that use a FFT to check if the input has frequencies > >> 16kHz, and informs the user that the file would not be encoded unless a >> -force parameter is specified (or at least ask the user if he or she want to >> do this :) ) >> Hopefully, this will reduce the number of files released on the internet, >> re-encoded from a lossy file format. Unfortunately, many users avoid using >> flac, because they think the encoder is lossy due to the poor sound on some >> files released. >> Thanks in advance. >> Sincerely, >> Jørgen Vigdal >> jor...@anion.no >> Phone: +47 91320132 >> jorgenvigdal.com >> ___ >> Flac-dev mailing list >> Flac-dev@xiph.org >> http://lists.xiph.org/mailman/listinfo/flac-dev >> >> ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Idea to possibly improve flac?
Its really sad to hear thats happening but even more sad is the fact that flac is becoming a very common format for music on the interweb whilst at the same time the development has ceased. I've found some severe issues with OggFLAC that essentially make it a useless format for streaming, no one cared. -David Listener of many flacs On Fri, Jan 7, 2011 at 3:42 PM, Jørgen Vigdal wrote: > Hi folks! > Due to the fact that more and more users increasingly use MP3 < 320kbps as > their source for encoding music, and publish it as flac files, I suggest > that something is done in the flac encoder to possible avoid this. > My idea is kinda easy/stupid, but might work; > Implement a function that use a FFT to check if the input has frequencies > > 16kHz, and informs the user that the file would not be encoded unless a > -force parameter is specified (or at least ask the user if he or she want to > do this :) ) > Hopefully, this will reduce the number of files released on the internet, > re-encoded from a lossy file format. Unfortunately, many users avoid using > flac, because they think the encoder is lossy due to the poor sound on some > files released. > Thanks in advance. > Sincerely, > Jørgen Vigdal > jor...@anion.no > Phone: +47 91320132 > jorgenvigdal.com > ___ > Flac-dev mailing list > Flac-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/flac-dev > > ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[Flac-dev] Idea to possibly improve flac?
Hi folks! Due to the fact that more and more users increasingly use MP3 < 320kbps as their source for encoding music, and publish it as flac files, I suggest that something is done in the flac encoder to possible avoid this. My idea is kinda easy/stupid, but might work; Implement a function that use a FFT to check if the input has frequencies > 16kHz, and informs the user that the file would not be encoded unless a -force parameter is specified (or at least ask the user if he or she want to do this :) ) Hopefully, this will reduce the number of files released on the internet, re-encoded from a lossy file format. Unfortunately, many users avoid using flac, because they think the encoder is lossy due to the poor sound on some files released. Thanks in advance. Sincerely, Jørgen Vigdal jor...@anion.no Phone: +47 91320132 jorgenvigdal.com___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
