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: Audio Tools Library 2.0 (Delphi) (Read 30113 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Audio Tools Library 2.0 (Delphi)

[span style='font-size:11pt;line-height:100%']Audio Tools Library 2.0 (Delphi)[/span]
Project main page: http://mac.sourceforge.net/atl


As Gambit posted in the New EncSpot like app thread, the MAC team developed a successor of Jürgen Faul's ATL and the following features were already added:
  • added OptimFROG component
  • added WavPack component
  • added Vorbis Comment component
  • added fpl component
  • many changes/updates/fixes
  • ATL is now released under the GNU LGPL license
At the same time the new ATL is used in Gambit's project Mr QuestionMan and he asked for better MP3 encoder detection, which was the reason for me to decide to try to enhance TMPEGaudio with a better encoder guess method. jtclipper is also interested in improving the old ATL, so we discussed things and decided to start a new thread concerning further ATL improvements.

This thread is ment for discussing and collecting improvement attempts and merge different code evolved during all that time from various developers. Anybody should feel free to contribute to the new ATL. For now the involved people are:

The MAC team (including Gambit), jtclipper and Feltzkrone

At the moment it's still unclear whether jtclipper and me (and maybe other people) are added to the developers for the MAC project (where the new ATL is part of) SourceForge.


People's current projects:
  • Gambit[span style='font-size:8pt;line-height:100%']
    • unknown
    [/span]
  • jtclipper[span style='font-size:8pt;line-height:100%']
    • unknown
    [/span]
  • Feltzkrone[span style='font-size:8pt;line-height:100%']
    • working on a new TMPEGAudio component
    • possible implementation of a buffered file stream component
    [/span]
This initial posting will be updated regularly on project changes.


@Gambit: Will you collect code by eMail or add us to the developers on SF?

Audio Tools Library 2.0 (Delphi)

Reply #1 –
Referring to my post reporting a bug in MAC v2.92 here I found the problem in the FlacFile unit and have made an updated version 1.2 (proposal), that I would like to be included in ATL. How's the correct way to do that?

..:: sundance ::..
 

Audio Tools Library 2.0 (Delphi)

Reply #2 –
So, here's the seperate thread for ATL improvements. Just to summarize what I was doing so far:

I started a new MPEGAudioEx.pas nearly from scratch and TMPEGAudioFrame and its subclasses do already perform the functions to read and decode frame headers and side information and to synchronize with a given stream.

For now MPEGAudioEx is working with stream objects only, but in order to be compatible to the old ATL the TMPEGAudio object will provide the same public methods and properties as the old one does. This will include a ReadFromFile method which takes a file name as the only parameter.

There are several questions which need to be answered:
1. Should a buffered file component be implemented and used internally?
2. Should a TAG manager component be written to enable reading of all known tags on all audio file type classes?
3. Should helper classes like TBitwiseStreamReader and possible TBufferedFileStream be seperated and put into a new helper unit?

IMHO all questions should be answered with Yes.

To summarize the capabilities of MPEGAudioEx here is a full class list and important, newly invented methods:
Code: [Select]
CLASSES 
  TBitwiseStreamReader = class;
  TMPEGAudioFrame = class;
  TMPEGAudioHeader = class;
  TMPEGAudioSideInfoChannel = class;
  TMPEGAudioSideInfoGranuleMono = class;
  TMPEGAudioSideInfoGranuleStereo = class;
  TMPEGAudioSideInfoMono = class;
  TMPEGAudioSideInfoNormalWindow = class;
  TMPEGAudioSideInfoSCFSI = class;
  TMPEGAudioSideInfoShortWindow = class;
  TMPEGAudioSideInfoStereo = class;

METHODS
  function ReadFromStream(Stream: TStream): Boolean; overload;
  function ReadFromStream(Stream: TStream;
        Offset: Integer): Boolean; overload;
  function ReadFromStream(Stream: TStream;
        Offset, SyncDistance, SubsequentFrames: Integer): Boolean; overload;


ReadFromStream is part of TMPEGAudioFrame and is able to:

- read a frame from the current position of a stream
- read a frame from a given position of a stream
- synchronize with a stream, given max. search distance & min. number of valid subsequent frames

When using a TMemoryStream (i.e. load all data from an MP3 file to the memory stream) it does take about 110ms to decode all headers and side information in case of a 14mb 192kbit file (prebuffering excluded). This means that it would take just around 8 seconds to scan 1gb for corrupt data (which in nearly all cases can be found by detecting synchronization loss) including decoding only, reading file data excluded.

Tested on a P4 2,4 GHz machine. Here is a log of my personal test program:
Code: [Select]
Loading file took 391ms
First frame found at: 1418
Resynchronization lost at position 8645022
Last frame at: 8645149
Scanning all frames took 61ms

Audio Tools Library 2.0 (Delphi)

Reply #3 –
Quote
[...], that I would like to be included in ATL. How's the correct way to do that?

You can email Gambit until it's clear if we get into the developers list on SourceForge. By the way: Wouldn't it make sense to open a seperate project on SourceForge?

Audio Tools Library 2.0 (Delphi)

Reply #4 –
Quote
Referring to my post reporting a bug in MAC v2.92 here I found the problem in the FlacFile unit and have made an updated version 1.2 (proposal), that I would like to be included in ATL. How's the correct way to do that?

..:: sundance ::..

I already sent an improved FLACfile.pas to be merged into ATL.

@Feltzkrone
Nice to see this thread BTW my current and .. everlasting project is TGF and I devote quite some time during weekends mostly to enhance it and generally evolve the program.

I can serve as a code reviewer , tester, enhancer or whatever, I already messed a lot with all the files in ATL and made custom made versions of them so I can do the things I want to be able to do in TGF.

The main thing missing from ATL right now is proper encspot like analysis, mp4 file format support and extended Unicode handling.
Dimitris

Audio Tools Library 2.0 (Delphi)

Reply #5 –
How it will influance Mpeg Audio Collection?

Audio Tools Library 2.0 (Delphi)

Reply #6 –
IMO, I don't think we need a separate project for ATL, since it's essentially a part of MAC. But I'll let you guys decide. jtclipper, what do you think? 

Oh, and as I said, if you are registered at SourceForge, give me your names and I will add you to the developers list and to the mailing list.

Audio Tools Library 2.0 (Delphi)

Reply #7 –
TMPEGAudioEx will probably be usable as a substitute for TMPEGAudio at the weekend except VBR file support. But I will try to finish this in time aswell.

Keeping it compatible to TMPEGAudio is hell. TMPEGAudio provides the useless Frame property which contains a record for a frame header data. But as TMPEGAudio has bugs you'll never know WHICH frame was read as the variable Position is filled with wrong values. I guess the Frame property was never used outside the class, but I'll replace it with an appropriate compatibility TMPEGAudioFrameCompat object or something which acts as a "translator" between the old TMPEGAudio.Frame property and the new TMPEGAudioFrameHeader class.

On the other side for my taste it's disgusting to have the ID3v1/ID3v2 and APE tags hardcoded in the class. I once thought about a TAudioTAGManager component which should be an aggregation of all possible audio file tags and I would like to do that once TMPEGAudioEx is finished (which means it has got at least the same functionality as old TMPEGAudio and has support for better encoder detection).

Audio Tools Library 2.0 (Delphi)

Reply #8 –
I think that since there are a lot of ATL 'mutants' out there including mine  there should be one project only containing the proposed code and yes it could be a MAC component.

The hard part is to find people to sit down and weed out the different flavors of the units into a single unified library and all of them to agree on that.

SF is the way to go I think but it would take some dedication and effort and since some late incidents threaten my job security I can not devote time on such projects at least till things clear up 
Dimitris

Audio Tools Library 2.0 (Delphi)

Reply #9 –
I have updated the WAV unit. Fixed some stuff and it can now trim samples from the beginning and from the end of a file. It can also search for digital silence at the beginning and the end of a wav so that you can use it like WavTrim.
There is still at least one bug left I forgot to fix (you must reload file info if you wanna trim the same file twice), but if anybody wants to test it, get it here:
http://burrrn.net/TehBukkake/ATL_WAV.zip

Audio Tools Library 2.0 (Delphi)

Reply #10 –
Did you take padding of the chunks into account? Some programs make a point of this. See the following link for an explanation of what is expected (under File Structure, second paragraph):
http://www.sonicspot.com/guide/wavefiles.html

Audio Tools Library 2.0 (Delphi)

Reply #11 –
The one problem I had with the ATL is that there are no proper higher-level classes that everything descends from. I was looking at the source, and there were several places that the code could be cleaned up and made better.

I was wondering if anyone else ever came across this and/or was bothered by it?

Audio Tools Library 2.0 (Delphi)

Reply #12 –
Yes, I am exactly thinking the same about ATL. What we need is a basic TAudio class and a basic and expandable TTag or TExtraInformation class.

TAudio should offer properties which EVERY audio file has got. Such things like playtime, eventually loops, bitrate, samplerate and sample resolution.

TTag should be capable of offering field names and field content, like databases do. If I want to access a song title from a tag the main program shouldn't need to be aware of WHAT Tag(s) is/are actually present.

It's the point to decide whether we want to keep the new ATL compatible to the old one OR we want to offer even more high-level and more flexible classes.

EDIT: Or maybe we should develop a new compatible ATL and a high-level ATL side by side.

Audio Tools Library 2.0 (Delphi)

Reply #13 –
Quote
Or maybe we should develop a new compatible ATL and a high-level ATL side by side.


I would second that approach.
And, there wouldn't be redundancy, if you keep the "low-level" routines (as they exist now in ATL) for compatibility reasons and introduce the basic classes like TAudio or TTag by referring to/using those.

Just my 2 cents...

Audio Tools Library 2.0 (Delphi)

Reply #16 –
- deleted - sorry, i posted in the wrong topic -
I am arrogant and I can afford it because I deliver.

Audio Tools Library 2.0 (Delphi)

Reply #17 –
Hi,

I have found a bug in "ape tag" library.

If I add an ape tag to an mpc then file will be corrupted.
I did some testing, and try to demonstrate:

Suppose the data in the file without ape tag is: ABCDEFG
File after tagging will be:  ABCDEF{apetag}
Data 'G' is missing and file is corrupt, winamp says sync error at the end of the file.
If I remove tag again, then the file will be: ABCDEF
Then I add tag again. The file will be: ABCDE{apetag}
Data 'F' is missing.
And so on.
The size of missing data ('F' or 'G') is always 32 Bytes, and it is the last 32 bytes before the tag's beginning.

Please somebody fix the bug, I need the library for my program.

Audio Tools Library 2.0 (Delphi)

Reply #18 –
I think I have found the bug:


old:
-------
function TAPEtag.RemoveFromFile(const FileName: string): Boolean;
var
  Tag: TagInfo;
begin
  { Remove tag from file if found }
  FillChar(Tag, SizeOf(Tag), 0);
  if ReadFooter(FileName, Tag) then
  begin
    if Tag.ID <> APE_ID then Tag.Size := 0;
    if (Tag.Flags shr 31) > 0 then Inc(Tag.Size, APE_TAG_HEADER_SIZE);
    Result := TruncateFile(FileName, Tag.DataShift + Tag.Size)
  end
  else
    Result := false;
end;
-------



new:
-------
function TAPEtag.RemoveFromFile(const FileName: string): Boolean;
var
  Tag: TagInfo;
begin
  { Remove tag from file if found }
  FillChar(Tag, SizeOf(Tag), 0);
  if ReadFooter(FileName, Tag) then
  begin
    if Tag.ID <> APE_ID then
      begin
        Tag.Size := 0;
        result:= true;
      end
    else
      begin
        if (Tag.Flags shr 31) > 0 then Inc(Tag.Size, APE_TAG_HEADER_SIZE);
        Result := TruncateFile(FileName, Tag.DataShift + Tag.Size);
      end;
  end
  else
    Result := false;
end;
-------


Seems to work, but I don't know if it will be ok in any case, since I do not even know what 'Tag.Flags' is and why to 'shr'.

What I am sure about is that when operating on a file that has no tag tag.flags' value was a huge negative number (overflow?). Then after shr-ing become greater than zero and file was truncated (32 byte = APE_TAG_HEADER_SIZE)

Audio Tools Library 2.0 (Delphi)

Reply #19 –
Audio Tools Library 2.1 released

  What's new:
- added TTA component
- added Speex component
- updated WavPack component
- added support for Lyrics3 v2.00 Tags to the ID3v1 component
- updated FLAC component
- updated WAV component
- updated MPEG Audio component
- some other updates/fixes to some components

http://mac.sourceforge.net/atl/

Audio Tools Library 2.0 (Delphi)

Reply #20 –
Quote
Audio Tools Library 2.1 released

  What's new:
- added TTA component
- added Speex component
- updated WavPack component
- added support for Lyrics3 v2.00 Tags to the ID3v1 component
- updated FLAC component
- updated WAV component
- updated MPEG Audio component
- some other updates/fixes to some components

http://mac.sourceforge.net/atl/

I like this (big) mac... 

Could you add AC3 and DTS components ?? It will be great...

Audio Tools Library 2.0 (Delphi)

Reply #22 –
I apologize if this isn't the correct thread for this but I have a request. I assume this library would allow someone to bang out an executable that simply takes an mp3 file and a string as the input and add a simple BAND id3v2 field to the mp3 file and insert the string into it?

I just can't seem to find a command-line tagger that does what I need. I tried tag.exe but it doesn't seem to write id3v2 tags.

I've got a pretty good routine worked out for ripping my CD's (EAC -> MAREO -> LAME -> FLAC) but the resulting mp3's are missing that key field which is needed for Windows Media Player (the BAND field is shown as "Album Artist" in WMP) Library feature, which is then read by Windows Media Center. If I had a simple command-line executable then I could add it to my mareo.ini so that it is executed every time I create an mp3.

I'd much appreciate it if someone could attempt to create a program for this purpose. I'd give it a shot if I knew how to develop in Delphi or pretty much any other programming language. If I have misunderstood this then let me know.