> 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 som
> 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 (mayb
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
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"
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
p
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
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 23
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 singl
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
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 dep
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,
> 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,
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 b
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
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.
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
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 int
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 indicat
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
> 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 fo
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
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 i
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 tog
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
> op
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
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 g
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 so
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 li
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 get
.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 anythi
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
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 receivi
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
> com
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
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
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
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
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. Certai
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
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 man
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 loo
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 Og
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
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 hear
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-
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 us
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 w
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
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 tha
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
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
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 int
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 ca
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 th
54 matches
Mail list logo
