Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: FLAC is no developing further? (Read 6647 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

FLAC is no developing further?

Their webpage is so quiet... there are no plans of improving it?

FLAC is no developing further?

Reply #1 –
The webpage or flac?  Jk, I know what you mean.  I like flac in its current state anyway, sure it may not produce as small files as optimFrog or others but it certainly is the most complete lossless codec IMO.

FLAC is no developing further?

Reply #2 –
Something else to consider, AFAIK FLAC is getting more hardware support than any other compressed lossless format out there, including the ever popular *.ape and *.shn.  The growing base of hardware players that are FLAC-friendly include the PhatNoise PhatBox/Music Keg, the new Rio Karma, and several others.

I don't remember reading anything here about Josh stopping development of FLAC, though he may be busy on other projects.  I agree with Bonzi...it's very stable and capable in it's current state, but that doesn't mean that nothing more can ever be done with it.

Plus, FLAC is now under the Xiph "umbrella" along with all the Ogg formats (Vorbis, Theora, etc.), so I would think it'll be getting even more attention/support/development in the future.

FLAC is no developing further?

Reply #3 –
I love FLAC, but I miss a lot the ability of tagging tracks individually in a FLAC file with an embedded cuesheet. It's really good to have only a file representing an album! But without the possibility of tag the tracks... it's not that useful

FLAC is no developing further?

Reply #4 –
Maybe FLAC should support (or better move over to) APEV2.0-tags. - That´s what I would wish for FLAC. And it also wouldn´t need much effort in programming it.
My used codecs and settings:
FLAC V1.1.2 -4 / APE V3.99 Update 4 -high / MPC V1.15v --q 5 / LAME V3.97b2 -V2 --vbr-new / OGG aoTuV V4.51 Lancer -q5

FLAC is no developing further?

Reply #5 –
Quote
Maybe FLAC should support (or better move over to) APEV2.0-tags. - That´s what I would wish for FLAC. And it also wouldn´t need much effort in programming it.


Reading & writing Vorbis-tags in FLAC is really easy
This is much thanks to the great documentation.

I agree that APE-tags is even easier to implement: You don't have to deal with rewriting the whole file if the tag doesn't fit, and there's always a standard way to find the tag (at the end).

But still; I think it's best to allow only Vorbis-tags in FLAC, because it's the standard way of storing tags. As stated in the flac specification: "This is the only officially supported tagging mechanism in FLAC."

Quote
I love FLAC, but I miss a lot the ability of tagging tracks individually in a FLAC file with an embedded cuesheet. It's really good to have only a file representing an album! But without the possibility of tag the tracks... it's not that useful


I also would like a standard way of storing tags for multiple files. I have some compilations of my own music (and others), and there's no way to get title/genre/etc for these from any database.

The current solution is to store all info in the external .cue-file.

It would be great if there could be some standard way, like TARTIST1, TTITLE1, TARTIST2, TTITLE2, ... which I believe was suggested in another thread (can't remember which thread is was).

FLAC is no developing further?

Reply #6 –
Quote
But still; I think it's best to allow only Vorbis-tags in FLAC, because it's the standard way of storing tags. As stated in the flac specification: "This is the only officially supported tagging mechanism in FLAC."


I agree with that

Having the tags in the cuesheet doesnt solve the problem, because I think the intention "--cueshet=" option to include .cue files  is to have all in one file.

I dont know why only some information of the .cue file is included and some is omitted (like FLAGS DCP or CD-TEXT). Some maniacs of the perfection (like me) want the possibility of burning the cd from the flac file exactly like it was. And almost all the information is in the cue file...

Just my opinion

FLAC is no developing further?

Reply #7 –
Quote
I dont know why only some information of the .cue file is included and some is omitted (like FLAGS DCP or CD-TEXT). Some maniacs of the perfection (like me) want the possibility of burning the cd from the flac file exactly like it was. And almost all the information is in the cue file...

and if you read the features of the project:
Quote
Convenient CD archiving: FLAC has a "cue sheet" metadata block for storing a CD table of contents and all track and index points. For instance, you can rip a CD to a single file, then import the CD's extracted cue sheet while encoding to yield a single file representation of the entire CD. If your original CD is damaged, the cue sheet can be exported later in order to burn an exact copy.


so it should work that way, me thinks.

/EDIT: oh yeah, and I want the option to specify the path in the installer! I don't want anything in my C:\Windows directory, which is where installer puts everything. I don't install anything on C it's only for OS and those damn files that just have to go there
The Plan Within Plans

FLAC is no developing further?

Reply #8 –
Quote
Quote
I dont know why only some information of the .cue file is included and some is omitted (like FLAGS DCP or CD-TEXT). Some maniacs of the perfection (like me) want the possibility of burning the cd from the flac file exactly like it was. And almost all the information is in the cue file...

and if you read the features of the project:
Quote
Convenient CD archiving: FLAC has a "cue sheet" metadata block for storing a CD table of contents and all track and index points. For instance, you can rip a CD to a single file, then import the CD's extracted cue sheet while encoding to yield a single file representation of the entire CD. If your original CD is damaged, the cue sheet can be exported later in order to burn an exact copy.


so it should work that way, me thinks.

FLAC doesnt store the complete cuesheet, as it skip some information like CD-TEXT for example...

Quote
"FLAC has a "cue sheet" metadata block for storing a CD table of contents and all track and index points."


It dont say anything about CD-TEXT 

FLAC is no developing further?

Reply #9 –
Quote
Their webpage is so quiet... there are no plans of improving it?

When it comes to codecs, the best way to "improve" them is to do something well, and then stay that way.  A codec's most useful feature is usability, and the way to increase usability is to be stable so that software and hardware makers are not afraid to use it.

People have all kinds of areas they think FLAC should improve:

"Codec XYZ gets slightly better compression ratio that FLAC."
The tiny % difference in file size is not worth making a codec more complex and more compute-intensive to decode.  It is also one of the reasons why FLAC is the only codec with hardware support, because none of the other ones, including WMA lossless, can decode in software on most embedded platforms.  (Shorten probably could, but the codec is not free and the file format is not practical.)

"Codec XYZ encodes slightly faster than FLAC."
So what?  As long as it keeps up with ripping, you won't even notice.  And remember, you encode once but decode often.

"FLAC hasn't had a release in a long time so it must be dead/inferior."
This is a good sign for FLAC.  Microsoft, as a defense tactic for crappy products, has brainwashed two generations otherwise, but a product that is stable and useful doesn't need fixing.  The next release of FLAC will have several fixes for minor bugs (minor meaning not affecting FLAC goals), a few improvements for Ogg FLAC and metaflac, and maybe a solution for whole-CD metadata (if I can think of one).

Quote
Maybe FLAC should support (or better move over to) APEV2.0-tags. - That´s what I would wish for FLAC. And it also wouldn´t need much effort in programming it.

Not gonna happen (at least not official support).  This goes back to usability, but another tagging format has to have significant advantages over the existing one, and APE2 doesn't.

Quote
I dont know why only some information of the .cue file is included and some is omitted (like FLAGS DCP or CD-TEXT). Some maniacs of the perfection (like me) want the possibility of burning the cd from the flac file exactly like it was. And almost all the information is in the cue file...


CD-TEXT is not part of the CD TOC, it's a stream in a subchannel.  You'll have to search the forums here for why it doesn't belong in the CUESHEET metadata.  Please find those threads before continuing.  On my TODO list is to eventually make a FAQ and this will be on it.

DCP is in the CD TOC but is contrary to the FLAC goals so it is not stored.  Anyway, it is always 'false' and so it carries no information.

Quote
/EDIT: oh yeah, and I want the option to specify the path in the installer! I don't want anything in my C:\Windows directory, which is where installer puts everything. I don't install anything on C it's only for OS and those damn files that just have to go there

Try asking Mike ("mw AT mikewren dot com"), he's pretty responsive to suggestions.

Josh

FLAC is no developing further?

Reply #10 –
I am not saying that FLAC is inferior because it is not updated. I only wanted to know if there was plans to improve to it. (If I thought that FLAC is inferior I wouldn't be so interesed in it  )

Quote
CD-TEXT is not part of the CD TOC, it's a stream in a subchannel. You'll have to search the forums here for why it doesn't belong in the CUESHEET metadata. Please find those threads before continuing. On my TODO list is to eventually make a FAQ and this will be on it.


I am not good at searching, my apologies. I found the reason after posting this message (there is too many information in this forum!).

FLAC is no developing further?

Reply #11 –
Sorry, I wasn't trying to put words in your mouth, I was just summing up some of the objections I get.  Soon these will all get merged into a FAQ.

Josh

FLAC is no developing further?

Reply #12 –
Quote
When it comes to codecs, the best way to "improve" them is to do something well, and then stay that way.  A codec's most useful feature is usability, and the way to increase usability is to be stable so that software and hardware makers are not afraid to use it.

Josh, that's a great post above.  It's great that HA exists to advance the technical side, but most of the time people here lose perspective on how real people adopt and  use a new product.  Usability, stability, backwards compatibility, cross platform compatibility, etc - just about all of those are more important than file size, it's inane how that's the obesession.

But I'd still remind you ... don't forget about developing the software interface!  The usability of the interfaces on Windows and Mac are a HUGE factor in how people perceive flac (or any other codec).  They could still use enhancement, as we discussed in another thread earlier.

FLAC is no developing further?

Reply #13 –
Quote
But I'd still remind you ... don't forget about developing the software interface!  The usability of the interfaces on Windows and Mac are a HUGE factor in how people perceive flac (or any other codec).  They could still use enhancement, as we discussed in another thread earlier.

The encoding format and the encoding front-end are two different things.  Sort of like a programming language vs. an IDE (integrated development environment...a "front-end" for coding).

AFAIK, Josh is the brain behind the FLAC encoding format...the "language" so to speak, but I don't think he's personally developed any of the front-ends.  The format was created, refined, and the specification was published to enable anyone in the world to create a "front-end" for FLAC (or any other aspect of its implementation).  PhatNoise's PhatBoxes and Music Kegs are FLAC-compatible, and PhatNoise Music Manager uses the reference FLAC encoder behind it's own front-end, the same used to encode to MP3, Vorbis, etc.  Winamp has a FLAC encoder front-end plug-in, as does foobar2000.  EAC can serve as a front-end if you manually "point it to" a FLAC encoder.  Then there is the FLAC frontend product, FLACdropXPd, etc.

I agree about the importance of ergonomics.  Interfaces are often under-emphasized when software is designed and developed.  But Josh's initial task is complete, IMO.  The FLAC format works.  And works well.  Now it's up to us and everyone else interested to get people to create implementations for FLAC, including nice, shiny encoder front-ends. 

FLAC is no developing further?

Reply #14 –
Quote
"FLAC hasn't had a release in a long time so it must be dead/inferior."
This is a good sign for FLAC.  Microsoft, as a defense tactic for crappy products, has brainwashed two generations otherwise, but a product that is stable and useful doesn't need fixing.  The next release of FLAC will have several fixes for minor bugs (minor meaning not affecting FLAC goals), a few improvements for Ogg FLAC and metaflac, and maybe a solution for whole-CD metadata (if I can think of one).

Well, one of the "features" FLAC surely inherited from MS's promotional tactics is releasing new versions full of new bells and whistles, but completely ignoring old, well known bugs.

Quoting Peter, foobar2000 developer:

Quote
Apparently FLAC developers prefer adding new "features" such as embedded cue rather than fixing issues or finishing other features they started adding before. In other words, yet another wonderful opensource project.
Bleh.

FLAC is no developing further?

Reply #15 –
Quote
Well, one of the "features" FLAC surely inherited from MS's promotional tactics is releasing new versions full of new bells and whistles, but completely ignoring old, well known bugs.

Quoting Peter, foobar2000 developer:

Quote
Apparently FLAC developers prefer adding new "features" such as embedded cue rather than fixing issues or finishing other features they started adding before. In other words, yet another wonderful opensource project.
Bleh.

Oops...  There are obviously some bugs in FLAC I haven't seen.  It seems two important remaining bugs as pointed out by Peter recently are ones I'd have never seen anyways.  I don't use Ogg containers for my FLAC encodings, and I'm not able to use FLAC tags (because of player compatibility...had to use ID3v2  ).

Oh well...even knowing the format is not perfect, most of my post is still valid, I hope (about the difference between the encoding format and the front-end).

FLAC is no developing further?

Reply #16 –
This isn't a new discussion, ScorLibran, see this thread, for example.  That comment was in hopes that the flac developers had reconsidered the conclusion that having the tools to enhance the real-world usability of flac was not their problem, or something they could influence.  (Though only if they want wider and more rapid adoption of the format - which could be a mistaken assumption on my part.  The flac code may in fact just be an end in itself for them.  I hope so, as that's the direction they're headed.) 

The sad thing is, I agree with Josh that it's a fairly trivial project in the scheme of things (though it wouldn't be for me; but I'd be glad to help fix the laughable "help" files if you'll fix the interface).  Too bad no one can be bothered to do such trivial work.

An interesting contrast might be par2 (another open source project).  Lots of effort has gone into developing and enhancing the interface of QuickPar (for Windows only, though - unfortunately nothing for Mac).  They do seem to be interested in whether people actually adopt and use par2.  The first version of the interface, released in May, was far superior to the front-ends for flac, and in a few short months it has been advanced a great deal - they've been getting feedback and enhancing it.  Take a look at QuickPar if you want an excellent example of how it should be done.  BTW, I'd say par2 has gained roughly as many users in the past few months as flac has since its inception.