IPB

Welcome Guest ( Log In | Register )

5 Pages V  < 1 2 3 4 5 >  
Reply to this topicStart new topic
Apple Lossless Audio Codec is now open source (Apache license)
kwanbis
post Nov 1 2011, 20:57
Post #51





Group: Developer (Donating)
Posts: 2361
Joined: 28-June 02
From: Argentina
Member No.: 2425



QUOTE (saratoga @ Nov 1 2011, 20:48) *
Well ok it changes nothing from an audio stand point. The warm fuzzy feeling you get is up to you smile.gif

I don't actually use ALAC, but in fact it does. It gives you the peace of mind that the ALAC you get, is 100% accurate. Maybe the reverse engineered version is 100% accurate also, but you never know for sure, and somebody already mentioned there was a problem with the FFMPEG implementation IIRC.


--------------------
MAREO: http://www.webearce.com.ar
Go to the top of the page
+Quote Post
saratoga
post Nov 1 2011, 21:28
Post #52





Group: Members
Posts: 4847
Joined: 2-September 02
Member No.: 3264



Err, you never know for sure that any code is bug free. As far as well know both encoders are lossless because everything they've encoded so far has been lossless, but that doesn't mean no bugs exist. So no it doesn't give that peace of mind, or if it does you're mistaken. If you want to know for sure, just verify that encoded file matches the input. This is trivial for lossless files and if its important to you then you should be doing it.

But anyway, my point was that for the situation you described (transcoding flac for use on an ipod), nothing at all has changed. Before you could trancode and be 100% sure the conversion was lossless (by checking) and afterwards you can continue to do the same (again, by checking).

I don't understand why you're having some much trouble understanding this. It seems pretty obvious to me smile.gif

This post has been edited by db1989: Nov 8 2011, 14:40
Reason for edit: removing unnecessary full quote of above post
Go to the top of the page
+Quote Post
marc2003
post Nov 1 2011, 21:38
Post #53





Group: Members
Posts: 4438
Joined: 27-January 05
From: England
Member No.: 19379



QUOTE (kwanbis @ Nov 1 2011, 19:32) *
Au contraire! It makes me sure that the ALAC i get would be totally official an 100% compatible.


erm.... http://sites.google.com/site/qaacpage/

Go to the top of the page
+Quote Post
Elbart
post Nov 1 2011, 22:38
Post #54





Group: Members
Posts: 43
Joined: 22-May 07
Member No.: 43683



QUOTE (googlebot @ Nov 1 2011, 19:36) *
I'm pretty sure that Apple has something coming for lossless mid- to long-term. They have no track record for releasing open source projects, that would else end up in the trash (or transition to pure maintenance mode), without ulterior motives.

AirPlay is using ALAC... laugh.gif
Go to the top of the page
+Quote Post
Phixion
post Nov 1 2011, 22:55
Post #55





Group: Members
Posts: 64
Joined: 7-September 07
Member No.: 46859



Can anyone point me in the direction of the new open source encoder for Windows please?

I know the source is @ http://alac.macosforge.org/ but I have no idea how to compile it and every google search leads me to the old, reverse engineered ALAC codec.

Many thanks.
Go to the top of the page
+Quote Post
Gregory S. Chudo...
post Nov 1 2011, 23:49
Post #56





Group: Developer
Posts: 689
Joined: 2-October 08
From: Ottawa
Member No.: 59035



Well, i did compile it, but the command line utility that comes with the library is not very useful - it only produces .caf format files, doesn't accept stdin for input and doesn't have any options. I have no idea if it works at all.
Attached File(s)
Attached File  alacConvert.exe.zip ( 91.27K ) Number of downloads: 214
 


--------------------
CUETools 2.1.4
Go to the top of the page
+Quote Post
kode54
post Nov 2 2011, 00:10
Post #57





Group: Admin
Posts: 4576
Joined: 15-December 02
Member No.: 4082



QUOTE (Gregory S. Chudov @ Nov 1 2011, 15:49) *
Well, i did compile it, but the command line utility that comes with the library is not very useful - it only produces .caf format files, doesn't accept stdin for input and doesn't have any options. I have no idea if it works at all.

I have verified that .caf files produced by the utility play in QuickTime X on OS X, but they don't play in iTunes.

Also, it would have been nice to know a way to check out the source with git or some other utility. I ended up downloading it file by file after I got the base download-in-original-format link from their Trac source browser.
Go to the top of the page
+Quote Post
Gregory S. Chudo...
post Nov 2 2011, 00:25
Post #58





Group: Developer
Posts: 689
Joined: 2-October 08
From: Ottawa
Member No.: 59035



You can check it out with SVN from here: http://svn.macosforge.org/repository/alac/trunk
For some reason this link doesn't appear anywhere on their site wink.gif

This post has been edited by Gregory S. Chudov: Nov 2 2011, 00:35


--------------------
CUETools 2.1.4
Go to the top of the page
+Quote Post
jfb
post Nov 4 2011, 00:13
Post #59





Group: Members
Posts: 1
Joined: 3-November 11
Member No.: 94930



QUOTE (nu774 @ Oct 29 2011, 16:43) *
It seems Apple's reference implementation gives incorrect magic cookie on little endian host.
In function ALACEncoder::GetMagicCookie():
CODE
theChannelLayout.mChannelLayoutTag = ALACChannelLayoutTags[theConfig.numChannels - 1];
--snip---
memcpy(theCookiePointer, &theChannelLayout, sizeof(ALACAudioChannelLayout));

In the upper line, mChannelLayoutTag is set without endian conversion, then it's just copied to the magic cookie buffer.
Probably this is not what they meant, since ALACSpecificConfig part is converted to big-endian.

I'm not seeing this; in the source, the mChannelLayoutTag is only set if the number of channels is > 2. For a stereo bitstream, there's no layout tag. But ffmpeg is still reading the header incorrectly, I think --

(from libavformat/cafdec.c:read_kuki_chunk()):

CODE
} else if (st->codec->codec_id == CODEC_ID_ALAC) {
#define ALAC_PREAMBLE 12
#define ALAC_HEADER 36
if (size < ALAC_PREAMBLE + ALAC_HEADER) {
av_log(s, AV_LOG_ERROR, "invalid ALAC magic cookie\n");
avio_skip(pb, size);
return AVERROR_INVALIDDATA;
}

I don't think those numbers are correct: the ALAC_PREAMBLE, (which I take to mean 'k' 'u' 'k' 'i' 00 00 00 00 00 00 00 18) is twelve bytes long; and ALAC_HEADER? Is this supposed to be the contents of the kuki chunk? Because that's a static size of sizeof(ALACSpecificConfig) for mono and stereo tracks, which is … 24 bytes. I'm not seeing where this 48 byte minimum size requirement is coming from? Regardless, this is a variable size -- if there are more than two channels, the size of the cookie payload is variable. I think this ffmpeg code is just wrong. Investigating further.
Go to the top of the page
+Quote Post
Ron Jones
post Nov 4 2011, 04:28
Post #60





Group: Members
Posts: 412
Joined: 9-August 07
From: Los Angeles
Member No.: 46048



QUOTE (Garf @ Oct 28 2011, 02:37) *
This doesn't help anyone but Apple. ffmpeg and libavcodec have supported ALAC decoding for approximately three years. These technologies have been in the open for a while despite Apple.

When it comes to coded audio formats, decoding is approximately half the battle. The options available for ALAC encoding on Windows are quite limited, for obvious reasons.

Given the nature of this technology and the current climate of lossless audio codecs, I don't see this as genuinely benefitting Apple to any great extent. If there's some major win they get out of this open sourcing, I couldn't describe what that major win could be.
Go to the top of the page
+Quote Post
Xenion
post Nov 4 2011, 13:26
Post #61





Group: Members
Posts: 1041
Joined: 23-May 02
From: DE
Member No.: 2107



QUOTE (marc2003 @ Nov 1 2011, 21:38) *
QUOTE (kwanbis @ Nov 1 2011, 19:32) *
Au contraire! It makes me sure that the ALAC i get would be totally official an 100% compatible.


erm.... http://sites.google.com/site/qaacpage/


which uses refalac now, exactly.
before apple opened the source of alac it relied on quicktime which gives you no guarantee of being a working solution in the future because of changes in quicktime making it incompatible with unsupported 3rd-party software.
Go to the top of the page
+Quote Post
Xenion
post Nov 4 2011, 15:58
Post #62





Group: Members
Posts: 1041
Joined: 23-May 02
From: DE
Member No.: 2107



Since it's opensource now, someone might compile a binary that is useable with EAC or any other CD-ripper. For people who share lossless audiolibraries on heterogeneous networks alac might be a good choice since mac users often prefer itunes (and alac is the only lossless format itunes can deal with)

This post has been edited by db1989: Nov 8 2011, 14:41
Reason for edit: removing unnecessary full quote of above post
Go to the top of the page
+Quote Post
saratoga
post Nov 4 2011, 16:41
Post #63





Group: Members
Posts: 4847
Joined: 2-September 02
Member No.: 3264



QUOTE (Xenion @ Nov 4 2011, 10:58) *
Since it's opensource now, someone might compile a binary that is useable with EAC or any other CD-ripper. For people who share lossless audiolibraries on heterogeneous networks alac might be a good choice since mac users often prefer itunes (and alac is the only lossless format itunes can deal with)


To be clear, you are aware that its been open source for years, and that people already have compiled a binary usable with EAC or any other CD-ripper, right? wink.gif
Go to the top of the page
+Quote Post
kwanbis
post Nov 4 2011, 18:55
Post #64





Group: Developer (Donating)
Posts: 2361
Joined: 28-June 02
From: Argentina
Member No.: 2425



QUOTE (Xenion @ Nov 4 2011, 15:58) *
Since it's opensource now, someone might compile a binary that is useable with EAC or any other CD-ripper. For people who share lossless audiolibraries on heterogeneous networks alac might be a good choice since mac users often prefer itunes (and alac is the only lossless format itunes can deal with).

Spoon would be able to implement a official ALAC encoder now wink.gif

QUOTE (saratoga @ Nov 4 2011, 16:41) *
To be clear, you are aware that its been open source for years, and that people already have compiled a binary usable with EAC or any other CD-ripper, right? wink.gif

The apple alac encoder/decoder?


--------------------
MAREO: http://www.webearce.com.ar
Go to the top of the page
+Quote Post
spoon
post Nov 4 2011, 20:19
Post #65


dBpowerAMP developer


Group: Developer (Donating)
Posts: 2741
Joined: 24-March 02
Member No.: 1615



Cue Microsoft in 3..2..1?


--------------------
Spoon http://www.dbpoweramp.com
Go to the top of the page
+Quote Post
Elbart
post Nov 4 2011, 22:21
Post #66





Group: Members
Posts: 43
Joined: 22-May 07
Member No.: 43683



QUOTE (Xenion @ Nov 4 2011, 15:58) *
Since it's opensource now, someone might compile a binary that is useable with EAC or any other CD-ripper. For people who share lossless audiolibraries on heterogeneous networks alac might be a good choice since mac users often prefer itunes (and alac is the only lossless format itunes can deal with)

Doesn't it need to be ported over first? Would be surprised if they made it multi-plat from the get-go.
Go to the top of the page
+Quote Post
JunkieXL
post Nov 5 2011, 00:38
Post #67





Group: Members
Posts: 359
Joined: 3-April 05
Member No.: 21165



You need to read this thread more closely. We are talking about Apple releasing their source code. Not some 3rd party that reverse engineered the ALAC codec. I also stated that above if you had read it.
JXL

This post has been edited by JunkieXL: Nov 5 2011, 00:39
Go to the top of the page
+Quote Post
hellokeith
post Nov 5 2011, 04:47
Post #68





Group: Members
Posts: 288
Joined: 14-August 06
Member No.: 34027



QUOTE (spoon @ Nov 4 2011, 14:19) *
Cue Microsoft in 3..2..1?

The only folks left in Windows Media are the Expression Encoder group. EE4 (free version) doesn't support AAC-LC output, so I doubt they'd be interested in this.
Go to the top of the page
+Quote Post
spoon
post Nov 5 2011, 08:54
Post #69


dBpowerAMP developer


Group: Developer (Donating)
Posts: 2741
Joined: 24-March 02
Member No.: 1615



Not MS supporting alac rather to release wmal as os


--------------------
Spoon http://www.dbpoweramp.com
Go to the top of the page
+Quote Post
saratoga
post Nov 5 2011, 19:44
Post #70





Group: Members
Posts: 4847
Joined: 2-September 02
Member No.: 3264



QUOTE (JunkieXL @ Nov 4 2011, 19:38) *
We are talking about Apple releasing their source code. Not some 3rd party that reverse engineered the ALAC codec. I also stated that above if you had read it.


I know what you are talking about. I didn't quote you because I was referring to Xenon's post rather then yours:

QUOTE
Since it's opensource now, someone might compile a binary that is useable with EAC or any other CD-ripper. For people who share lossless audiolibraries on heterogeneous networks alac might be a good choice since mac users often prefer itunes (and alac is the only lossless format itunes can deal with)


Theres already an open source encoder available that you can use with EAC. Hence my point that theres already an open source encoder that you can use with EAC. I realize that you made a different post above about a different thing, but since I was not referring to it, I did not quote it.

Is that clear?
Go to the top of the page
+Quote Post
Destroid
post Nov 8 2011, 01:21
Post #71





Group: Members
Posts: 545
Joined: 4-June 02
Member No.: 2220



Well, of course everything Apple is lame and Steve was the icon of a-holiness and his best iFollowers kept his brain and his ding-dong alive in jar. (btw, this is a sarcastic joke)

Ok, seriously I'll bench the official ALAC encoder because I also was a little put-off by the unofficial encoder and its reputation of not being error-proof. I just don't think I'll see any dazzling scores from it, probably a bit better than FLAC compression wise with slower encode speeds. To what niche does ALAC have outside Apple products? I can't say and wouldn't predict it to catch on too quick, FLAC has quite a bit more notoriety at the present.


--------------------
"Something bothering you, Mister Spock?"
Go to the top of the page
+Quote Post
Wombat
post Nov 8 2011, 02:06
Post #72





Group: Members
Posts: 977
Joined: 7-October 01
Member No.: 235



QUOTE (Destroid @ Nov 8 2011, 02:21) *
Ok, seriously I'll bench the official ALAC encoder because I also was a little put-off by the unofficial encoder and its reputation of not being error-proof. I just don't think I'll see any dazzling scores from it, probably a bit better than FLAC compression wise with slower encode speeds. To what niche does ALAC have outside Apple products? I can't say and wouldn't predict it to catch on too quick, FLAC has quite a bit more notoriety at the present.

We wonīt see much better compression. Gregory Chudovīs libalac already maxes out what ALAC can archieve at best. Its compression is better as the standard flac 1.21 but also worse as libflake/FlacCL from Gregory.
At least on my testcorpus. On some material ALAC is much worse like Lossywav or with empty bits in files.
I already asked Gregory if we can expect better compression from this source code and the answer wasnīt positive.
When i remember right there was some speculation about wasted bits ability of ALAC but now that the code is open there isnīt something to expect in that direction.
Besides that when you got used to GPU encoding with FlacCL most other codecs are slow. Wanting the tiny bit better high compression from libalac already needs much processing power and ALAC is not good for GPU.

Also i wonder why ALAC on the lossless wiki is said to decode "very fast". On my machine the foobar decoding test shows it at half the speed a flac -8 file decompresses at best.
Even alacConvert.exe decoding the *.caf file is much slower.
Go to the top of the page
+Quote Post
jukkap
post Nov 9 2011, 08:05
Post #73





Group: Members
Posts: 26
Joined: 14-July 11
Member No.: 92296



QUOTE (Destroid @ Nov 8 2011, 02:21) *
probably a bit better than FLAC compression wise with slower encode speeds.


I've found out that Apple's ALAC encoder is extremely fast encoder. I compiled Apple ALAC with Intel C++ max optimized. I'll do better ALAC vs. FLAC comparison later.

The Apple's reference ALAC encoder reads/writes the files in too short blocks and it slows down dramatically its performance.

This post has been edited by jukkap: Nov 9 2011, 08:06
Go to the top of the page
+Quote Post
spoon
post Nov 9 2011, 10:51
Post #74


dBpowerAMP developer


Group: Developer (Donating)
Posts: 2741
Joined: 24-March 02
Member No.: 1615



QUOTE
Either way you look at it, there is little reason for Apple to start selling ALAC files other than to appeal to a relatively small group of people.


When selling anything you need to keep ahead of the game, if Apple have the bandwidth + eco system to do so, it would not negatively impact them, rather it would put unexpected costs onto Amazon, etc to keep up with the game. Apple would put up a page explaining to Joe Public that the new offering (only costing 30c to upgrade your existing m4a purchases to) is the highest CD quality, where as the existing stuff purchased has less quality, people are not going to do listening tests, they would pay the 30c per track and Apple would have 12 months of healthy increased revenue (plus the lossless tracks would likely cost more also).


--------------------
Spoon http://www.dbpoweramp.com
Go to the top of the page
+Quote Post
Wombat
post Nov 9 2011, 15:12
Post #75





Group: Members
Posts: 977
Joined: 7-October 01
Member No.: 235



QUOTE (jukkap @ Nov 9 2011, 09:05) *
QUOTE (Destroid @ Nov 8 2011, 02:21) *
probably a bit better than FLAC compression wise with slower encode speeds.


I've found out that Apple's ALAC encoder is extremely fast encoder. I compiled Apple ALAC with Intel C++ max optimized. I'll do better ALAC vs. FLAC comparison later.

The Apple's reference ALAC encoder reads/writes the files in too short blocks and it slows down dramatically its performance.

Appleīs default compression must be pretty lousy likle between -3 and -4 for flac
Go to the top of the page
+Quote Post

5 Pages V  < 1 2 3 4 5 >
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 24th July 2014 - 10:57