Author Topic: New: Ogg Vorbis and Opus Tag Library Delphi component  (Read 4220 times)

3delite

  • Posts: 907
Hi!

First release of Ogg Vorbis and Opus Tag Library for Delphi is available.

Ogg Vorbis and Opus Tag Library is a component for use in Win32 (9x/ME/2K/XP/Vista/W7), Win64 and OSX software.
Reads and writes Ogg Vorbis and Opus tags (tags in Ogg Vorbis and Opus audio files).

Features:

  • Loading of Ogg Vorbis and Opus tags
  • Saving of Ogg Vorbis and Opus tags
  • Removing of Ogg Vorbis and Opus tags
  • Supports binary frames and cover pictures
  • Access directly all tags as a TMemoryStream (full control of the tag contents)
  • Full unicode support
  • Pure Delphi code, no external dependencies
  • Delphi XE2 64bit and OSX compatible

Official home page: Ogg Vorbis and Opus Tag Library

Not tested that much so far. Please report any bugs found!

EDIT: Sorry no cover art support yet as stated before! Now I looked into it and it's not that simple that I thought, but the simple tagging works fine so far. Please give me some time and I'll try to implement it too. Sorry!
« Last Edit: 19 Dec '12 - 14:07 by 3delite »

3delite

  • Posts: 907
Re: New: Opus Tag Library Delphi component
« Reply #1 on: 5 Dec '12 - 11:58 »
Managed to make it work!

The OGG stream handling is completely re-written, cover arts are supported, Foobar2000 loads them fine.
Please note that it is not yet tested much as this is the first release of the new stream handling.

Please report any issues! :)

3delite

  • Posts: 907
An update is available!

Added support for reading and writing of Ogg Vorbis tags, so now the component is renamed to Ogg Vorbis and Opus Tag Library.
Also there is a fix for writing Opus tags which are exactly dividable by $FF.

Again, first version, may contain bugs.

fmcoder

  • Posts: 436
Strange... It creates "C:\CVB.raw" file when trying to read a tag.

3delite

  • Posts: 907
Ooops... sorry a line for debugging purpose was left in the release version.

An update is now up on the download page.

Thank you for the notice!

fmcoder

  • Posts: 436
OK. But there's another issue I noticed (likely that it exists in your other libraries): You silence exceptions with try... except end; blocks. That's not good. This can silence AV exception, and then, couple of hours later, program will crash in some other, totally unrelated code. You should catch only known exceptions. Eg. if you're opening a file, catch EFOpenError. When working with streams - EStreamError, and so on.

Minor:
* why code formatting is different from Delphi standard?
* I've noticed couple of commented-out code blocks - why are they present in the release version?
* To call this function
Code: [Select]
function GetPictureFromFrame(Index: Integer; var PictureStream: TStream; var PictureType: Cardinal; var MIMEType: AnsiString; var Description: String; var Width: Cardinal; var Height: Cardinal; var ColorDepth: Cardinal; var NoOfColors: Cardinal): Boolean; - one needs to define 7 (!) variables just to get non-important information. Better practice would be to use a record.

Anyway, the idea of creating tagging libraries for Delphi is great :) I've spent several months in the past writing my own :) Probably for some file types I'll switch to your libraries.

3delite

  • Posts: 907
Thank you for your suggestions!

I don't think you're right about 'silence AV exception' issue. AVs should not happen at all, but when the code is running in real life, then for example when you are processing 100 files my code would not stop in the middle because of an exception. But if a write happens to a wrong memory location then it's totally indifferent whether there's a try...except or not because an exception will only happen if the memory location falls out of the allowed access range. If it's illegal then it won't be allowed and there's no corruption, if it happens to an allowed location then it would also happen without the tr..except block.

I format my code the way I like it best. The Delphi standard style was developed 15 years ago (or more?), I work on a HD monitor I have space not to fit one line into 80 character wide display and I think my style is the most readable, at least for me. :)

The commented out code blocks are left in because they can be informative. I do remove code blocks from the release which are not needed for sure. And sorry but I don't want to manage 2 versions of the code, one for developing and one for release.

About I should use a record for those variables topic, you're completely right.

Cool if you use my libraries in your project, thank you! :)

fmcoder

  • Posts: 436
I don't think you're right about 'silence AV exception' issue.
You silence exception, it means you won't get an error message/bugreport from the place where exception actually happened. But then, most likely, program will crash somewhere else. Even if you're using madExcept or something - bug report will contain no useful information (because the real source of problem was buried in except-end, and the code where crash happened has nothing to do with it).

If the exception is not silenced, then the bugreport will come from the real location -therefore it will be easier to locate a problem.

I format my code the way I like it best. The Delphi standard style was developed 15 years ago (or more?), I work on a HD monitor I have space not to fit one line into 80 character wide display and I think my style is the most readable, at least for me. :)
It's up to you, but most Delphi Component developers follow Borland coding style.

Cool if you use my libraries in your project, thank you! :)
Yes, currently I'm testing your libraries, if everything is good - you'll have couple of orders :)

3delite

  • Posts: 907
Ah, I understand you now. But if so, what would you say about processing 100 files and an exception occurs and whole processing stops just because one exception/bad file? The user would be angry. ::)

Ok, that's cool. If you encounter a bug, please tell me, and I'll try to fix it ! :)

« Last Edit: 6 Mar '13 - 09:18 by 3delite »

fmcoder

  • Posts: 436
Ah, I understand you now. But if so, what would you say about processing 100 files and an exception occurs and whole processing stops just because one exception/bad file? The user would be angry. ::)
User will be angry when program crashes with no apparent reason because 10 minutes (or 2 hours ago) ago an AV was silenced.

If you process 100 files, and you get an exception which you can handle (eg. EFileOpen, EStreamError) - that's fine. Process those in the Except block, return an error code, move on to the next file. If you have an exception you can't handle - don't do anything with it, let it go the the next exception handler.

When EAccessViolation, EOutOfMemory or something like this occurs - crash immediately. Silencing this will only delay an inevitable crash :)

Error handling is one of the most important parts of programming. Especially if you're writing components for other developers.

3delite

  • Posts: 907
Ok, googled it and read about it some articles. I'll try to improve my exception handling mechanism in my components, thank you for the notice! :)