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: Yalac: Tagging Scheme (Read 6694 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Yalac: Tagging Scheme

Quote from: TBeck on
And thanks for the table. And not to forget: for your speed graph from the previous post! It took me some time to find it....
Yeah, my link wasn't the best I guess.  For others who missed it, here's a better link (same graph).  I must also thank Josef as the idea really came from a similar graph he sent me comparing my results with his.  I mean, graphs aren't a new invention, but I personally find it a lot more descriptive than the figures by themselves.

Quote from: TBeck on
To give an first estimate: About 0.02 percent for seeking and error checking when using 250 ms frames. More for Fast and Turbo because of their smaller frames.

But i don't know, how large the average tagging info is.
I don't think the size would be great.  To be honest I was  thinking more of the impact on speed than compression anyway (although the compression amount is obviously very much of interest also).  I have always assumed that we will see some minor drops in compression once you add seeking and error checking.  The main priority is getting Yalac in a position where that loss is not too disadvantageous to Yalac.

I am hoping that you will use APEv2, which seems to be a very sensible tagging scheme.  With that in mind the additional KiB for tagging would only be equivalent for WavPack, etc.  I can't imagine that FLAC's Vorbis comments take up less room than APEv2.  Either way it will be negligable anyhoo.  Ooh, I'm getting really OT now.
I'm on a horse.

Yalac: Tagging Scheme

Reply #1 –
id3v2 can be padded 4kb.

Yalac: Tagging Scheme

Reply #2 –
Please Lord, no!

ID3v1 is 128 bytes, if memory serves.  Now there's a way to save some KiB...

NB: There is a copy of the APEv2 specification in the wiki.  It does look very simple and minimal, while being very flexible.  64 bytes of header and footer plus (9 + <key+value in UTF8> bytes) for each tag.

I'm going to have to split this thread soon... unless we just change the title.
I'm on a horse.

Yalac: Tagging Scheme

Reply #3 –
I actually don't really care what tags YALAC support.  Embedded cuesheets would be nice;  I presume you can store those in an apev2 tag. I think the tags should be padded in yalac, nevertheless, to prevent fragmentation and rewrites.  Maybe 1Kib is enough.

Yalac: Tagging Scheme

Reply #4 –
1KiB padding with embedded cuesheets would be a curious combination.

I believe APEv2 are usually at the end of a file (strongly recommended), which makes padding unnecessary, if I understand correctly.  You would just need to rewrite the last few KiB (all tags) at worst.

APEv2 just seems like a very sensible/lean tagging scheme, whereas ID3v2 doesn't (unclear specification, too many variations), and ID3v1 is too limiting.
I'm on a horse.

Yalac: Tagging Scheme

Reply #5 –
1 KiB of padding is maybe not sufficient if you want to embed cuesheets all the time;  most of my cuesheets tend to be around 5 kiB once I add all the replaygain, metadata, date, bpm for each track, etc.

As for placement of the tag, is there any serious advantage to having it at the beginning of the file?  Who streams lossless audio?  (I guess there are hardware A/V rack players that do...)

This is just a crazy idea, but would it be possible to have a tag at the end AND the beginning...  have them simultaneously updated by software?

The tag at the end could take precedence and contain any arbitrary metadata, photos, cuesheets, etc, and the tag at the beginning could be forced to a limit of 1 KiB, and contain only the "standard" fields limited to so many bytes (so in other words, a bigger and automatic version of ID3v1... fixed size).

OT, perhaps, but what was the idea of making ID3v1 at the end of the file and limited in size, and ID3v2 at the beginning of the file and wildly varying in size?  Isn't that a little backwards from how it should be, since the entire file needs to be rewritten if a tag at the beginning of the file changes?

Yalac: Tagging Scheme

Reply #6 –
I like the idea of a mini-tag at the beginning.  Perhaps id3v1, but restricted fields?  We need to consider unicode, though.  Tracknumber, Artist, Album and Title only need to be written -- that way, a hardware player could stream it without any problems and display the info.

Those tags together would easily fit in 1-2Kib  After which, you could always add APEv2 at the end of the file, unpadded, or maybe padded just a bit in case of tag changes. 8KiB would do it, I think. It's fairly large, but if you consider double-width unicode characters, it's just enough with embedded cuesheets

Yalac: Tagging Scheme

Reply #7 –
I don't know too much about the APEv2 spec, but does it allow for embedded multimedia content, like ID3v2 apparently does?

I guess in theory, you could allow someone to embed 10 Megs of images into the file or something.  I have no use for this, personally, but I know that some people like to embed at least an album cover in their songs, perhaps more relevant in a singlefile lossless image than anywhere else.

Unicode is a really good idea, at least for the tag contents. The ability to specify arbitrary metadata fields, with many predefined ones also makes a lot of sense, but I think this stuff is already thought of.  I don't think TBeck needs to really design anything new, just implement one of the good existing standards.

Yalac: Tagging Scheme

Reply #10 –
Hrm... it seems my last reply disappeared into a black hole or something.
Anyway, I was saying that a 30 character limit is way too little, as many titles and names don't fit into that space.  I'm not a fan of ID3v1's limitations.  Why did the designer originally think that 128 bytes was a good size anyway?  What was wrong with 256 bytes?  Was it something to do with being substantially smaller than a frame?

Anyway, here's another idea:
Is it possible to make a single file CD image with arbitrary metadata for each track part of the tagging spec?  i.e. have one file with 20 songs in it, and have a different title, artist, genre, bpm, and date for each song?

That would be really useful for some of what I've been doing, although I'm probably going to just drop it and start ripping to single files at this point, because it's getting to be way too much work to maintain and use my cuesheet + imagefile system.

I just was wondering if it's possible without some non-standard extended cuesheet type of system.

Yalac: Tagging Scheme

Reply #11 –
This may be completely ignorant of me to ask, but why not just create a new, proprietary tagging system? Obviously I don't know what that entails, so maybe that in itself is asking a lot when work is already being done on the encoder and format itself.

I guess I'm just a purist in the sense that you can take ideas from one place, and make them better; make them your own.

The one downside to that would probably be getting support for said tagging system, but if you think about it, you're already going to need to get support for the format anyway.

Yalac: Tagging Scheme

Reply #12 –
I'm not sure how it works, reading tags... but if you design something that's simple to read, it shouldn't be a big deal to implement it.

I think that Winamp Input plugins are themselves responsible for reading the tags, and most likely this is similar with foobar.  It shouldn't be a huge problem to have a proprietary tagging system, but it might be unnecessary to "reinvent the wheel", so to speak.

Yalac: Tagging Scheme

Reply #13 –
Quote from: Supacon on
It shouldn't be a huge problem to have a proprietary tagging system, but it might be unnecessary to "reinvent the wheel", so to speak.


I agree with you completely. What I'm saying is now we need to add spokes to that old wheel, to re-inforce it. Give it some rims to make it look good.

There are a lot of good tagging systems out there, but some are missing features that other ones have. The whole idea for this format is to create something that's better, more efficient. Shouldn't it be the same with the tagging system? Shouldn't the entire package be as good as it can be? It'll encourage competition or, at the very least, humiliate it. 

Yalac: Tagging Scheme

Reply #14 –
Quote from: ozmosis82 on
There are a lot of good tagging systems out there, but some are missing features that other ones have. The whole idea for this format is to create something that's better, more efficient. Shouldn't it be the same with the tagging system? Shouldn't the entire package be as good as it can be? It'll encourage competition or, at the very least, humiliate it. 
This is partially true : I don't think an open standard which probably won't support DRM will be adopted by many companies; as such, instoring a new tagging system will force companies that want to implement the codec to implement yet ANOTHER tag reading method.  It's simply not an effective use of time. Hell, to be "standard-compliant", we'd have to use id3v2.3. As in everything, though, it's fair game either way.

Yalac: Tagging Scheme

Reply #15 –
Quote from: Shade[ST on
as such, instoring a new tagging system will force companies that want to implement the codec to implement yet ANOTHER tag reading method.  It's simply not an effective use of time.
Agreed.

If you use APEv2 at the end of the file any app that can currently read and/or write APEv2 tags (e.g.: Tag or Wapet) can be used with no need for changes.

I believe (I hope this isn't wrong) David Bryant simply used the code from Wapet to add inline tagging to WavPack.  It makes sense to reuse proven code.

I will admit that I am talking as someone who does not place much importance on tagging.  As long as I can add a cuesheet, and/or the standard ID3v1 tags, I am happy.  APEv2 will let me do this in a concise way.

I must admit I like the idea of the MP4 and Ogg chapters, but if you need that for a lossless file people are used to using a CUESHEET tag.  FLAC's cuesheet meta block does not seem to be widely used (mainly due to the meta data stripping, I know).

On the subject of inline tagging:  I would very much like to be able to tag while encoding, as per LAME, FLAC, WavPack, Ogg, etc.  Monkey's Audio falls down on that one.
I'm on a horse.

Yalac: Tagging Scheme

Reply #16 –
Even though I have no real idea of how this works, I imagine that writing the tags to the end of the file is better. When adding more information, the data can simply be written to the end of the file, and the audio data does not have to be rewritten. This might speed up tagging a lot. And with APEv2 being an open standard, implementing it might not be too hard. And as Synthetic Soul pointed out, the working code can just be taken from an existing project. This is one of the big advantages of Open Source, so why not use it?

Yalac: Tagging Scheme

Reply #17 –
The "mini tag" idea seems like an interesting one. Maybe it won't fit all the information, but I don't see that it needs to since it's only used in select circumstances.

Yalac: Tagging Scheme

Reply #18 –
I completely agree with the opinion that it is more of a burden than an advantage to implement another tagging scheme that the world has never heard of.  Apev2 works, and I haven't heard complaints about it.  Sure, perhaps something more innovative could be developed, but is it really necessary?

Ideally, since this should be a great codec, people will adopt it quickly.  If for every software tool and player out there, new code needs to be written from scratch to allow the tags to be written, that will hamper and slow down adoption considerably.

But in that vein... (OT, perhaps), will YALAC be easy to port to other platforms?  Hardware/DAPs? Linux?

Yalac: Tagging Scheme

Reply #19 –
Quote from: Supacon on
But in that vein... (OT, perhaps), will YALAC be easy to port to other platforms?  Hardware/DAPs? Linux?


Yalac is currently, I believe, in Delphi with x86 ASM optimizations for MMX and SSE (?)
Thomas was thinking, again IIRC, about porting it to C or C++, which would be a fair rewrite, though not throwing away everything.  Following that, the GUI part of the software is obviously platform-specific, also.  Otherwise, it's 14 bit arithmetic, integer-only, so it should be VERY fast and easy to port to other hardware, provided the switch to C is done already.