FLAC 1.1.1-beta1 released

Topic: FLAC 1.1.1-beta1 released (Read 35522 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.

FLAC 1.1.1-beta1 released

Reply #25 – 2004-08-02 03:24:53

Xiph.org's stance on Vorbis comments has always been that Vorbis comments are for short comments, such as what you would scribble on a CD-R. If you need something more weighty, you'd be better off muxing in text files or a metadata stream.

FLAC uses Vorbis comments too. If you want large amounts of embedded metadata, I'd personally suggest muxing in Ogg $Plaintext or Ogg Writ or Ogg $Metadata together with Ogg FLAC.

FLAC 1.1.1-beta1 released

Reply #26 – 2004-08-02 03:31:09

Quote

Quote
But why? What does it do that the current setup (with padding) cannot accomplish?
[a href="index.php?act=findpost&pid=230757"][{POST_SNAPBACK}][/a]

cause when you change a tag, you could end up rewriting all the file ... like in ogg
[a href="index.php?act=findpost&pid=230927"][{POST_SNAPBACK}][/a]

kwanbis, would you need more than 4 kilobytes of comments about each of your FLAC files? If not, you wouldn't end up rewriting the whole file.

FLAC 1.1.1-beta1 released

Reply #27 – 2004-08-02 05:02:59

Quote

Please don't "Skip" all this information. It renders Flac invisible to the professional audio world.

My profound thanks for Flac, regardless.
Tony
[a href="index.php?act=findpost&pid=230967"][{POST_SNAPBACK}][/a]

Just curious...

Is there a lossless codec that meets these requirements?

FLAC 1.1.1-beta1 released

Reply #28 – 2004-08-02 11:56:52

tev777 & kjoonlee> I don't see the point to switch to a complex container (matroska &/or ogg) just for adding a text to a file. Tags are an easy way to do it; they are very easy to edit; it's also very easy to access to the information. I can't say the same thing with containers (which need CLI tools for muxing, demuxing, editing...).

XIPH conception of tag is different of mine ; I need something else than poor and limited informations alla freedb. Other lossless and lossy formats allow this for a long time, and the use of tags with these formats is not enfeoff to the will of one developer. It's a real asset for tags located at the end of the stream.

FLAC 1.1.1-beta1 released

Reply #29 – 2004-08-02 12:01:11

Quote

Is there a lossless codec that meets these requirements?
[a href="index.php?act=findpost&pid=231015"][{POST_SNAPBACK}][/a]

David Bryant mentioned to me he was saving some specific Metadata on CoolEdit/Audition. I think that also applies to WAV chunks.

FLAC 1.1.1-beta1 released

Reply #30 – 2004-08-02 16:09:05

Quote

I ask you all to beat it up and let me know what you find.
[a href="index.php?act=findpost&pid=230686"][{POST_SNAPBACK}][/a]

Just for fun I ran 3122 WAV files (which I got from decoding FLAC 1.1 files with 1.1) through 1.1.1-beta1 and compared the decoded WAV with the original. Not a byte was out of place.

FLAC 1.1.1-beta1 released

Reply #31 – 2004-08-02 16:59:16

Quote

Quote
I ask you all to beat it up and let me know what you find.
[a href="index.php?act=findpost&pid=230686"][{POST_SNAPBACK}][/a]

Just for fun I ran 3122 WAV files (which I got from decoding FLAC 1.1 files with 1.1) through 1.1.1-beta1 and compared the decoded WAV with the original. Not a byte was out of place.
[a href="index.php?act=findpost&pid=231128"][{POST_SNAPBACK}][/a]

Hey, I thought this thread was for beating up on various tagging schemes, what's with the testing post?

Oh, right

(edit: put quotes in wrong place!)

FLAC 1.1.1-beta1 released

Reply #32 – 2004-08-02 19:02:44

Quote

Please save away all the metadata chunks in WAV files along with the audio.

Without support for saving away data like that, Flac cannot be used to archive audio in the professional broadcast and film range, which will usualy be in the Broadcast WAV format, which just adds a bunch of chunks to the file.

Flac skips this stuff atm, thereby destroying all the information contained within. This information includes timecode values and various forms of descriptions. Virtualy all the recent audio database software uses meta data in Broadcast WAVs to store information on the specific sound, which it then integrates in to its databases. To rebuild the database in case of loss these applications simpy scans all the Broadcast WAVs for metadata.

I should probably make a FAQ out of this since you're not the first person that has asked... FLAC is not a compressed WAVE file formet, it's an audio compressor. It's purpose is not to reproduce a WAVE file, including all the stuff that's in it. flac just happens to know how to get audio data out of a WAVE file.

If I added that, what about AIFF? AIFF users might then expect all AIFF files to be reproduced exactly.

Also, it would add a lot of complexity to flac because non-audio data has to go in the metadata section which is at the beginning of the FLAC file. But in WAVE it can go before or after the audio, so the encoding would have to make multiple passes and also store the chunk hierarchy to be able to reproduce it.

If someone really needed such a thing they could write a postprocessor to put skipped chunks into FLAC metadata after encoding, and do the opposite when decoding. Or use a suitable codec (LPAC, maybe RAR or MAC).

Quote

Wildcard support for windows is not working yet.
I thought it would be added on the next version (this version )

It turns out because of the botched way long filenames are done in FAT32 that there are non-intuitive side-effects. My current plan is to keep flac.exe as is and maybe include a flacglob.exe or something that does the wildcard expansion via setargv.obj.

Quote

XIPH conception of tag is different of mine ; I need something else than poor and limited informations alla freedb. Other lossless and lossy formats allow this for a long time, and the use of tags with these formats is not enfeoff to the will of one developer. It's a real asset for tags located at the end of the stream.

You're mixing metaphors with freedb. Your only real complaint is that they're at the front, not the end. Other formats may put tags on the end, but the only one that does and plays outside of a PC is MP3 with ID3v1, which is very simple. What you want requires compromises that are not acceptable for a general purpose codec. I'm not sure what you meant by 'enfeoff' but it's not the will of one developer any more than is your request the demand of one user.

Tags will stay the way they are in FLAC.

Josh

FLAC 1.1.1-beta1 released

Reply #33 – 2004-08-02 19:46:49

Quote

Quote
XIPH conception of tag is different of mine ; I need something else than poor and limited informations alla freedb. Other lossless and lossy formats allow this for a long time, and the use of tags with these formats is not enfeoff to the will of one developer. It's a real asset for tags located at the end of the stream.

You're mixing metaphors with freedb.

I answered to kjoonlee argument, which was according to him a quotation of Xiph.org recommandation: "Vorbis comments are for short comments, such as what you would scribble on a CD-R"
...and so are freedb tags: elementary informations.
I think that I have the right to use the tagging system for something else, and to associate consequent informations to an audio files. It works with all audio files around there, without problem. Only exceptions are maybe the "totally free" vorbis and flac format.

Quote

Other formats may put tags on the end, but the only one that does and plays outside of a PC is MP3 with ID3v1, which is very simple

Did you ever heard the name of iPod?
Curiously, MP4 tags associated to M4A files generated by iTunes are located on the end. Doesn't seems to be a problem for manufacturer like Apple.

Quote

What you want requires compromises that are not acceptable for a general purpose codec.

Could you then explain me why OptimFROG, WavPack, TTA, MPC, etc... have accepted this "unacceptable" compromise? It sounds to me like a simple feature rather than a compromise or something like that.

Quote

I'm not sure what you meant by 'enfeoff' but it's not the will of one developer any more than is your request the demand of one user.

I suppose that the lossless "streaming" argument, which is the main justification of tags located at the beginning of a file, is also something very popular on this board

Quote

Tags will stay the way they are in FLAC

.

I'll see...
I'm just surprised that flac officially or semi-officially supports two similar tagging system, which both have the same advantages and the same flaws.

FLAC 1.1.1-beta1 released

Reply #34 – 2004-08-02 21:23:07

Monkeys Audio supports this, and has done so for over two years now. It's not the most important feature to most folks.

Flac is crossplatform and has exellent decompression speeds, and is wonderfully free. But it's DOA for archiving audio libraries of sound designers and post production places. The meta data in the extra chunks is too important and availability through simple universially available tools would have been nice to have. I don't see it happening anymore now. Nobody's going to write a tool for this. It's either in the format, or it isn't.

Thanks anyway. I use Flac to archive non-metadata ridden files.

Btw, nobody uses AIFF for audio archiving in broadcasting. That's what the BWAV is for.

FLAC 1.1.1-beta1 released

Reply #35 – 2004-08-02 21:26:28

Quote

tev777 & kjoonlee> I don't see the point to switch to a complex container (matroska &/or ogg) just for adding a text to a file.

Why should a user be interested in the complexity of a container ? The devs should care, but why the users ? You guys simply use tools, and they should be doing what you like them to do. The underlying complexity of simplicity shouldnt mean anything to you ? If so, why ?

Quote

Tags are an easy way to do it; they are very easy to edit; it's also very easy to access to the information. I can't say the same thing with containers (which need CLI tools for muxing, demuxing, editing...).

CLI tools ? did you ever find mmg, the GUI coming with mkvmerge ? For tag editing once the file is made, use the matroska shell extension from Windows Explorer, or the CDL coming with TCMP, or Foobar2000. As matroska usually puts tags at the end of the file, there is also no rewriting of the files necessary ....

FLAC 1.1.1-beta1 released

Reply #36 – 2004-08-02 21:53:05

I'm not familiar to matroska. I tried to make some mka file, but it wasn't really intuitive. Even with GUI, this kind of tagging (adding text or something else) need a third-party program. An audioplayer is more convieniant, for many reason I don't think necessary to explain
Anyway, I'll be interested by matroska when easy tools will be available; but now, I don't have any benefit to use any container - complex or not is not the question.

EDIT:

Quote

Why should a user be interested in the complexity of a container ?

I wasn't clear on my last message. It's not the complexity of the container that could annoy me, but the complexity of the tools. Generating and tagging an audio file is easier than creating and tagging a matroska container with an audio file inside.

FLAC 1.1.1-beta1 released

Reply #37 – 2004-08-02 22:10:55

Quote

On a big library, the amount of padded information could be important: 200...500 MB. I know that HD storage is cheap nowadays, by this kind of waste is specific to flac:
[a href="index.php?act=findpost&pid=230796"][{POST_SNAPBACK}][/a]

Heh.. those 200-500MB would contain tags for 100-250GB of FLAC'd music (assuming an average file size of 30MB and 64KB padding) - dunno about you, but whining about such a minute "waste" of disk space strikes me as pretty ridiculous. Especially when considering that a good deal of those 200-500MB are used up by actual metadata, if you really tend to put such novels into your tags as you claim to. *shrug*

FLAC 1.1.1-beta1 released

Reply #38 – 2004-08-02 22:26:24

I have 6000 lossless tracks. Two 120 GB HD are close to be full, and my library is still growing.
FLAC have many interesting things, but two worse aspect for my own usage:
- encoding ratios (flac are 5,5% bigger than Monkey "normal", which means 14 GB of spared space by using Monkey).
- tagging system, for reasons I've explained. Padding is an acceptable solution, but it mean, for safety, that I need to waste even more space.

I'm interested by Flac because it's fast (for transcoding, or opening in any editor). I could accept to use more space for flac, because it offers me a real gain (in speed). But I don't see the point to waste extra-space for padding, which offers me nothing. That's all.

Support for APEv2 or any other solution (vorbis_comment located at the end) could be interesting for some people, which are not using (or expect using) lossless for portable players or for streaming purpose. It's just what I'm thinking. No need then to use matroska, ogg to solve problems, no need to waste space with padding, no need to check if the ripping programm or the encoding gui offer the possibility to add padding, etc...
Now, if it's problematic for developers, I could understand. I've just asked to Josh if he planned to do it. I didn't asked to be tried for a behaviour different from the masses.

FLAC 1.1.1-beta1 released

Reply #39 – 2004-08-03 19:21:02

I think trying to pass off an additional "waste" of let's say ~400MB out of ~240,000MB or roughly 0.16% of your disk space as an argument that bears any significant relevance in this debate is quite petty. I mean, really..

FLAC 1.1.1-beta1 released

Reply #40 – 2004-08-03 19:32:01

I recently decided to re-tag several GB of FLAC files. Basically, I was just adding track numbers and genre information. I have no idea why, but a large portion of the files needed to be re-written. It took quite a long time. Disc thrashing the whole time.

So, while the disc space was not really important to me, the time to re-tag them was. I don't understand why they needed to be re-written. There were already tags in the files. I was just adding track numbers, etc.

FLAC 1.1.1-beta1 released

Reply #41 – 2004-08-03 20:06:35

Indy,

Possibly whatever you used for tag editing added extra tag fields. Media Jukebox/Center are I apps I know of that do this. Another possibility...the tags didn't exist beforehand (which would necessitate a rewrite). Padding is applied to existing tags only AFAIK.

xen-uno

FLAC 1.1.1-beta1 released

Reply #42 – 2004-08-03 20:13:01

Personally, I think flac should encode to Ogg FLAC by default and use the ogg container for all of the metadata. The ogg container should have the flexibility to place the tag at either the beginning of the file or the end of it and it should support compression of subtitle/lyrics/notes etc. (gzip, bzip and 7zip are good open sourced compression methods to consider for text compression) This should cure the confusion with tagging within xiph formats and this kind of flexibility should fit most people's need. I think it's a waste of flac developers' time to reinvent and maintain files formats and metadata scheme: there are already plenty of good solutions available and their time is better spent on improving the encoding/decoding efficiency/speed of flac stream instead of addressing the problems with tags. Plus, having a common container also allows difference streams to be mixed together (ie. speex stream for speech mixed with vorbis stream for background music mixed with theora for video mixed with text stream for subtitle).

FLAC 1.1.1-beta1 released

Reply #43 – 2004-08-03 21:05:41

Quote

I recently decided to re-tag several GB of FLAC files. Basically, I was just adding track numbers and genre information. I have no idea why, but a large portion of the files needed to be re-written. It took quite a long time. Disc thrashing the whole time.

So, while the disc space was not really important to me, the time to re-tag them was. I don't understand why they needed to be re-written. There were already tags in the files. I was just adding track numbers, etc.

not sure what you used to re-tag, but either 1) there was not enough padding to cover the increased size; or 2) the tagger was not using the padding efficiently.

libFLAC has two interfaces for editing metadata; one is more memory efficient and the other is optimally padding efficient. if you're interested, the API docs describe how padding is used in both.

http://flac.sourceforge.net/api/group__flac__metadata.html

metaflac uses the padding-efficient version. the winamp2 plugin uses the memory-efficient version, but needs to be changed to the padding-efficient one.

Josh

edit:

Quote

Another possibility...the tags didn't exist beforehand (which would necessitate a rewrite). Padding is applied to existing tags only AFAIK.

padding can be consumed to account for growing tags or new ones.

FLAC 1.1.1-beta1 released

Reply #44 – 2004-08-04 05:46:16

Quote

I'm not familiar to matroska. I tried to make some mka file, but it wasn't really intuitive. Even with GUI, this kind of tagging (adding text or something else) need a third-party program. An audioplayer is more convieniant, for many reason I don't think necessary to explain
Anyway, I'll be interested by matroska when easy tools will be available; but now, I don't have any benefit to use any container - complex or not is not the question.

http://www.hydrogenaudio.org/forums/index....617&hl=matroska

A script to create MKA's directly from EAC, and including all tags taken from the CUE sheet. Cant be much easier, dont you think .....

FLAC 1.1.1-beta1 released

Reply #45 – 2004-08-04 18:35:42

Quote

I recently decided to re-tag several GB of FLAC files. Basically, I was just adding track numbers and genre information. I have no idea why, but a large portion of the files needed to be re-written. It took quite a long time. Disc thrashing the whole time.[a href="index.php?act=findpost&pid=231553"][{POST_SNAPBACK}][/a]

The task you describe is inherently disk-intensive. In fact, I'm betting that if you checked the file sizes you'd find out that they are exactly the same size they were before -- you didn't "re-write" the files at all.

Consider how disk drives designed for desktop computers work. They have typically a 2 MB or an 8 MB cache. Typical desktop users access patterns are such that the best performance can be achieved in normal usage by reading ahead after an access, so that subsequent reads will come out of the cache.

In your task, you only need one block of data near the beginning of the file.

But, the disk drive, trying to be helpful loads its cache up with the next portion of the same file. If your disk is not perfectly defragmented, then the heads will be skipping all over the disk trying to ready the next cache-ful of data for you. Now you write the tags back out and ask for a totally different file. The disk drive dumps its cache, gets you the first block of the new file, and, once again, takes off over the disk trying to buffer up the next part of the file.

Step and repeat.

The lesson here is that if you know you are going to perform a task like this, make sure your A/V drive is well-defragmented before you start, and even then, expect some disk thrashing.

FLAC 1.1.1-beta1 released

Reply #46 – 2004-08-04 18:49:56

Ummm, no, not really.

Without getting into a debate about which is format is better, all I can say is that I was able to do the same task, on several THOUSAND Wavpack files, in about 20 seconds. No disc thrashing.

The FLAC files took about 20 minutes to do about half as many files on the same 7,200 RPM/8MB cache SATA drive, using the same tagging software, adding the same type of information.

FLAC 1.1.1-beta1 released

Reply #47 – 2004-08-04 18:56:54

I suspect your tagging software was buggy if it didn't take advantage of the padding. You didn't delete your padding, did you?

FLAC 1.1.1-beta1 released

Reply #48 – 2004-08-04 19:00:02

Quote

I suspect your tagging software was buggy if it didn't take advantage of the padding. You didn't delete your padding, did you?
[a href="index.php?act=findpost&pid=231873"][{POST_SNAPBACK}][/a]

As I said before. The files ALREADY had tags.

I only added track numbers and genre information. It is possible that the tagging software and/or the method I used was the problem. However, it only was a problem for some of the FLAC files, not all. And all of them had the same type of tags to start with.

Edit: I'm not complaining, I only asked because I thought it was strange. I'm also not wanting to compare FLAC to Wavpack. I like FLAC, and I like Wavpack. One works better for me than the other.

FLAC 1.1.1-beta1 released

Reply #49 – 2004-08-04 21:14:24

Quote

I only added track numbers and genre information. It is possible that the tagging software and/or the method I used was the problem. However, it only was a problem for some of the FLAC files, not all. And all of them had the same type of tags to start with.

there's no way to get any closer to an explanation without knowing what tagging s/w you used. if you had tags and padding already and you just added a track number it can't be a problem with FLAC.

Josh

Notice