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

TTA

Reply #25 –
Quote
It's a difference in bitrate calculation.
1 Kbit = 1024 bits, not a 1000.

Could you explain the reason behind that?

Personally, I am not aware of any audio format that would use such a convention.

TTA

Reply #26 –
2 guruboolez: Thank you for good words about TTA.

Quote
Encoding ratios are nevertheless worse than MAC -c2000 (the encoder I choose for my library) : 4-6 MB per disc (tested on three discs only).


Yes. I have a difference about 2-3 MB per album (~400Mb) approx., but it depends from data. In fact TTA 3.0 compression ratio corresponds to MAC fast mode, but we don't use Intel specified assembler optimizations; It's realy multiplatform codec; TTA format has no restrictions for number of audio channels; Algorithm has a minimal system requirements and can be implemented into the most of popular DVD players without a specialized chips.

-- Alexander

TTA

Reply #27 –
Quote
Yes. I have a difference about 2-3 MB per album (~400Mb) approx., but it depends from data.

2-3 MB?
Strange. I listen to classical music mainly, and bitrate with lossless is less impressive : 570...600 kbps on average (I obtained 41% ratio on 300 CD).
I couldn't test for the moment on more than three discs (stored on my notebook), but the difference is > 2..3 MB :

Code: [Select]
    SCELSI
APE    214 Mo (224 505 884 octets)
TTA    219 Mo (230 166 109 octets)

    HAYDN
APE    222 Mo (233 703 319 octets)
TTA    227 Mo (238 842 259 octets)

    VIVALDI
APE    293 Mo (308 005 231 octets)
TTA    299 Mo (313 857 299 octets)


Difference is more annoying, though it's far from a dramatic situation. On a 120 GB hard disk, I'll probably lose 7 or 8 albums.
 

TTA

Reply #28 –
Quote
I couldn't test for the moment on more than three discs (stored on my notebook), but the difference is > 2..3 MB

Sorry, from our tests it's really about 4-6 Mb difference (per album) ;-)

Quote
On a 120 GB hard disk, I'll probably lose 7 or 8 albums.

TTA was not developed to reach a top of compression results. Unfortunately it's unpossible now to get a high (1-3% better) compression ratio and keep a hardware compatibility. 4-6 Mb difference (per album) - it's about 1.5%. On a 120 GB hard disk, you will probably lose only 1,8 Gb. Real difference here in count of software/hardware wich is/may support this format. TTA project develops fast. Many of the TTA supported software are planned this year.

-- Alexander

TTA

Reply #29 –
Quote
Quote
It's a difference in bitrate calculation. 1 Kbit = 1024 bits, not a 1000.

Could you explain the reason behind that?

Personally, I am not aware of any audio format that would use such a convention.

It's a right calculation. Without any doubtful goals ;-)
I don't want to divide by 1000 because it gives a not true result.
This calculation is not format depended. If you prefer to see a wrong bitrate value - you can to correct it by yourself. TTA code is open.

-- Alexander

TTA

Reply #30 –
Quote
Quote
Quote
It's a difference in bitrate calculation. 1 Kbit = 1024 bits, not a 1000.

Could you explain the reason behind that?

Personally, I am not aware of any audio format that would use such a convention.

It's a right calculation. Without any doubtful goals ;-)
I don't want to divide by 1000 because it gives a not true result.
This calculation is not format depended.

You're wrong about this.

The only context in which 1 kb = 1024 b is memory, for historical and technical reasons (physical memory always comes in powers of 2).

When it comes to disk space consumption - which is relevant in the context at hand - 1 kb is 1000 b.
A riddle is a short sword attached to the next 2000 years.

TTA

Reply #31 –
Quote
New TTA plugin for Foobar2000 has appeared. Hope it looks better.
Changes from previous version:

  - Code rewrited using Foobar reader system;
  - Fixed CUE files playback.

ftp://tta.iszf.irk.ru/ttaplugin-foobar-2.4-20040430.zip

It has problems with sync on track change when plays via CUE. Get some gapless image for testing.
Igor

TTA

Reply #32 –
Computers count in powers of two. Kilo in the context of a computer means 1024. End of story. Want proof? Right click on ANY file in windows and look at how the size information is calculated. Look at the capacity your OS reports for your "40 Gig" hard drive (HD manufacturers have long calculated their sizes using powers of 10 in order to make their drives look bigger).

I will accept 1000 bytes in a kilobyte when there are 10 bits in a byte.

TTA

Reply #33 –
*puts on pedantic hat*

Actually, the official term for 1024 bytes is a kibibyte, not a kilobyte.  Kibibyte, however, sounds stupid, so kilobyte still gets a lot of use even though it's technically wrong.  As for TTA, if the other input plugins are using kilo- to mean 1000, it'd probably be a good idea to conform to that, even though it's not really too big of a deal.

*throws pedantic hat in woodchipper*

TTA

Reply #34 –
Thanks for all. It's really my mistake. It's incredibly, but for dynamic bitrate calculation 1Kbit equal to 1000 bit  I will to correct the bitrate calculation in all of TTA plugins.

"Examples of quantities or phenomena in which power-of-10 prefix multipliers apply include frequency (including computer clock speeds), physical mass, power, energy, electrical voltage, and electrical current. Power-of-10 multipiers are also used to define binary data speeds. Thus, for example, 1 kbps (one kilobit per second) is equal to 103, or 1,000, bps (bits per second); 1 Mbps (one megabit per second) is equal to 106, or 1,000,000, bps. (The lowercase k is the technically correct symbol for kilo- when it represents 103, although the uppercase K is often used instead.)

When binary data is stored in memory or fixed media such as a hard drive, diskette, ZIP disk, tape, or CD-ROM, power-of-2 multipliers are used. Technically, the uppercase K should be used for kilo- when it represents 210. Therefore 1 KB (one kilobyte) is 210, or 1,024, bytes; 1 MB (one megabyte) is 220, or 1,048,576 bytes."

-- Alexander

TTA

Reply #35 –
I uploaded new modified TTA plugins to my page, download binaries or sources.
Changes:
Sample accurate seeking, correct bitrate display, multi-instance safety (only old version  was buggy), streaming support, configuration for selecting tag format and turning on/off realtime bitrate display.
Edit: and lossless decoding of IEEE floating point TTA files.

TTA

Reply #36 –
I've heard all the kibi/mebi/gibi stuff before. I don't buy it. When you are talking about an inherently binary system it makes sense to talk about it using binary terms, and the *established* prefixes are kilo, mega, giga, despite any SI connotations they might have. Not to mention you sound like an idiot saying stuff like "mebibyte."

I'll accept the new prefixes when I see them actually used by someone other than someone who has been reading way too many "standards" documents for their own good.

TTA

Reply #37 –
re-read the second paragraph of Alexander's (ald) last post.


Additionally, allow me to quote a bit more from the text Alexander already quoted from (since you're probably not going to do any own research on this issue anyway):

"The choice of power-of-10 versus power-of-2 prefix multipliers can appear arbitrary. It helps to remember that in common usage, multiples of bits are almost always expressed in powers of 10, while multiples of bytes are almost always expressed in powers of 2. Rarely is data speed expressed in bytes per second, and rarely is data storage or memory expressed in bits. Such usages are considered improper. Confusion is not likely, therefore, provided one adheres strictly to the standard usages of the terms bit and byte."

Keep in mind that audiovisual media are usually regarded as streams, not as files - hence the usage of kbps, and hence the use of powers of 10.
A riddle is a short sword attached to the next 2000 years.

TTA

Reply #38 –
Quote
I uploaded new modified TTA plugins to my page..

Thank you for your work. Going to look at you code now.
1 question: In my SDK I have no a DECLARE_FILE_TYPE macro..
Where can I get this macro if it requered for Foobar?

Please check this plugin also:

NEW TTA PLUGIN (BETA)

ftp://tta.iszf.irk.ru/ttaplugin-foobar-2.4-20040502.zip

ftp://tta.iszf.irk.ru/ttaplugin-foobar-2.4-20040502.zip

  - Fixed CUE files playback;
  - APEv2 tags support;
  - Tagging type selection;
  - Corrected VBR calculation;
  - Display VBR configuration option.

Thanks in advance for comments.

-- Alexander

TTA

Reply #39 –
Quote
NEW TTA PLUGIN (BETA)

ftp://tta.iszf.irk.ru/ttaplugin-foobar-2.4-20040502.zip

ftp://tta.iszf.irk.ru/ttaplugin-foobar-2.4-20040502.zip

  - Fixed CUE files playback;
  - APEv2 tags support;
  - Tagging type selection;
  - Corrected VBR calculation;
  - Display VBR configuration option.

Thanks in advance for comments.

-- Alexander

Really good one for my playback images via CUE. But it has one (i hope last) problem:

Part of CUE file:
TRACK 01 AUDIO
  TITLE "xxx"
  PERFORMER "xxx"
  FLAGS DCP
  INDEX 01 00:00:00
TRACK 02 AUDIO
  TITLE "xxx"
  PERFORMER "xxx"
  FLAGS DCP
  INDEX 00 02:46:60
  INDEX 01 02:50:53
TRACK 03 AUDIO
  TITLE "xxx"
  PERFORMER "xxx"
  FLAGS DCP
  INDEX 00 05:04:66
  INDEX 01 05:09:04
TRACK 04 AUDIO
  TITLE "xxx"
  PERFORMER "xxx"
  FLAGS DCP
  INDEX 00 07:54:41
  INDEX 01 07:58:53

3 images: .ape, .flac, .tta. I decoded track01, track02, track03 and track04 in a separate files. All tracks decoded from ape and flac are bit-identical. Track02 and Track04 decoded from tta have 1 extra sample in the beginning.
Igor

TTA

Reply #40 –
Quote
Track02 and Track04 decoded from tta have 1 extra sample in the beginning.

Have you tried the same with Case's version of the plugin?

~ Florian

TTA

Reply #41 –
Quote
Quote
Track02 and Track04 decoded from tta have 1 extra sample in the beginning.

Have you tried the same with Case's version of the plugin?

~ Florian

Yes.
Track01 - bit-identical.
Track02 - different samples at 00.000-00.032
Track03 - different samples at 00.000-00.028
Track04 - 1716 missing samples at 00.000 (flac/ape) and 1716 missing samples at 00.065 (tta)
Igor

TTA

Reply #42 –
Quote
1 question: In my SDK I have no a DECLARE_FILE_TYPE macro..
Where can I get this macro if it requered for Foobar?

You need latest SDK.

TTA

Reply #43 –
Quote
Please check this plugin also:

NEW TTA PLUGIN (BETA)

ftp://tta.iszf.irk.ru/ttaplugin-foobar-2.4-20040502.zip

ftp://tta.iszf.irk.ru/ttaplugin-foobar-2.4-20040502.zip

  - Fixed CUE files playback;
  - APEv2 tags support;
  - Tagging type selection;
  - Corrected VBR calculation;
  - Display VBR configuration option.

Some nice improvements but few issues: seeking isn't sample accurate, you disallow playback of streams and floats are clipped to linear PCM scale.

I used some of the new improvements in my modified version and fixed the seeking issue reported by rii. Download binaries and sources.

Also included in my latest special installer.

TTA

Reply #44 –
Quote
Some nice improvements but few issues: seeking isn't sample accurate, you disallow playback of streams and floats are clipped to linear PCM scale.

Thanks again for your help. Please look at the final version.
Preferences/About also interesting 

RELEASE?
(Mostly of Case modifications included)

ftp://tta.iszf.irk.ru/ttaplugin-foobar-2.4-20040502.zip

ftp://tta.iszf.irk.ru/ttaplugin-foobar-2.4-src-20040502.zip

Any additional wishes?

-- Alexander

TTA

Reply #45 –
Quote
Any additional wishes?

Sure, while you're at it..


This is not directly related to foo_tta, but to ttaenc in general: please add support for encoding from stdin and decoding to stdout. This would enable direct transcoding to and from tta, without the need to create a temporary wav file.

(it'd allow for better TTA support in foo_clienc as well )
A riddle is a short sword attached to the next 2000 years.

TTA

Reply #46 –
Quote
This is not directly related to foo_tta, but to ttaenc in general: please add support for encoding from stdin and decoding to stdout.

OK. I will, but at now I must make my part of code for new auCDtect release.

Later..

-- Alexander

TTA

Reply #47 –
Some ideas or wishes about TTA itself:
- embedded md5 hash, like Monkey Audio, could be nice (for quick checking a entire library, especially on low CPU).
- CoolEdit/Audition filter is also a nice tool.

Anyway, nice progress since 48 hours (corrected bitrate, APEv2 support). Thanks.

TTA

Reply #48 –
Quote
Some ideas or wishes about TTA itself:
- embedded md5 hash, like Monkey Audio, could be nice (for quick checking a entire library, especially on low CPU).
- CoolEdit/Audition filter is also a nice tool.

MD5 hash is not required. Each TTA frame has it's own CRC32. For checking a big libraries it's better to use some of special multimedia library organizers.. I think.

CoolEdit/Audition filter is planned.

-- Alexander

TTA

Reply #49 –
Quote
For checking a big libraries it's better to use some of special multimedia library organizers.. I think.

I don't understand.
Correct me if I'm wrong, but there are two ways for checking files:
- full decoding.
- CRC or MD5 verification.

The first way is probably the best (more accurate), but the second is much faster. On large library (mine is now >6000 lossless files) and slow CPU, full decoding is really fastidious. Verification takes one hour with the second methodology on my computer, and more than a complete night with the traditional decoding tool.
What do you think?