IPB

Welcome Guest ( Log In | Register )

6 Pages V  < 1 2 3 4 5 > »   
Closed TopicStart new topic
flac 1.3.0 pre-release
eahm
post Mar 9 2013, 20:17
Post #51





Group: Members
Posts: 884
Joined: 11-February 12
Member No.: 97076



Can anyone please post the exe? ...or instructions of how to compile since I've never did it once?

Thanks.

This post has been edited by eahm: Mar 9 2013, 20:18
Go to the top of the page
+Quote Post
romor
post Mar 9 2013, 20:33
Post #52





Group: Members
Posts: 650
Joined: 16-January 09
Member No.: 65630



Here it is, flac-1.3.0pre2 exe with metaflac, compiled with MSVC: http://db.tt/x87ItNjC


--------------------
scripts: http://goo.gl/M1qVLQ
Go to the top of the page
+Quote Post
Musique-Rabbit
post Mar 10 2013, 03:44
Post #53





Group: Members
Posts: 38
Joined: 1-March 06
Member No.: 28173



Thanks romor, the pre2 is working fine for me. The ref lib is 1.2.1xxx, not 1.3xxx?
Go to the top of the page
+Quote Post
Mach-X
post Mar 10 2013, 07:05
Post #54





Group: Members
Posts: 242
Joined: 29-July 12
Member No.: 101859



just out of curiosity does anyone here go all willy nilly and re rip all their cds with each new flac version just to stay "bleeding edge"? I dont even remember which version I have...its whatever came with eac...
Go to the top of the page
+Quote Post
johnb
post Mar 10 2013, 09:45
Post #55





Group: Members
Posts: 33
Joined: 15-November 03
From: Munich
Member No.: 9858




Why would you need to re-rip? Only recode (foobar converter), if at all.
Go to the top of the page
+Quote Post
skamp
post Mar 10 2013, 09:50
Post #56





Group: Developer
Posts: 1343
Joined: 4-May 04
From: France
Member No.: 13875



From what I can tell, there are no compression improvements in this version. You don't have to either re-rip or transcode your FLAC 1.2.1 collection.


--------------------
caudec.net
Go to the top of the page
+Quote Post
romor
post Mar 10 2013, 13:22
Post #57





Group: Members
Posts: 650
Joined: 16-January 09
Member No.: 65630



Binary is provided as user asked for it, and it's there for testing. There can't be any reason for re-encoding, or using beta version over next 1.3.0 version or previous release.

More patches are supplied, and final flac version will hopefully make flac build system breeze on supported platforms, and perhaps attract more developers and further extend in the future.

Some changes are mentioned in this thread and git change log is linked in first post.
More accessible change log should also be provided soon, AFAIK


--------------------
scripts: http://goo.gl/M1qVLQ
Go to the top of the page
+Quote Post
Porcus
post Mar 10 2013, 13:24
Post #58





Group: Members
Posts: 1779
Joined: 30-November 06
Member No.: 38207



QUOTE (Mach-X @ Mar 10 2013, 07:05) *
just out of curiosity does anyone here go all willy nilly and re rip all their cds with each new flac version just to stay "bleeding edge"?


As others pointed out, re-ripping for the sake of a new lossless encoding is absolutely no point.

Myself I converted all my FLAC 1.1.x files to 1.2 simply because I otherwise would have too many FLAC versions in the Codec or Codec profile list in fb2k when selecting multiple items. It was too annoying to scroll past the FLACs in order to see if there was any other filetypes selected. I am still not confident that FLAC's overwrite is safe (anyone?), so I selected every 1.1.x file in fb2k, converted to a different drive with directory structure preserved, imported, bit-verified audio as identical, overwrote, and removed bit-identical files using XXCOPY. I am not sure if fb2k preserved album art, but I have that as folder.jpeg, front.jpeg and back.jpeg anyway.


--------------------
One day in the Year of the Fox came a time remembered well
Go to the top of the page
+Quote Post
ktf
post Mar 10 2013, 23:02
Post #59





Group: Members
Posts: 305
Joined: 22-March 09
Member No.: 68263



QUOTE (Musique-Rabbit @ Mar 10 2013, 03:44) *
Thanks romor, the pre2 is working fine for me. The ref lib is 1.2.1xxx, not 1.3xxx?

I just found out that for MSVC, there's a libFLAC version number (1.2.1 in this case) "hard coded" into the source, which explains why you're seeing files with such a vendor string appearing. I've notified the devs of this problem.


--------------------
Music: sounds arranged such that they construct feelings.
Go to the top of the page
+Quote Post
eahm
post Mar 11 2013, 00:24
Post #60





Group: Members
Posts: 884
Joined: 11-February 12
Member No.: 97076



Also why the date is up to 2009 and not 2013?
Go to the top of the page
+Quote Post
ktf
post Mar 11 2013, 08:26
Post #61





Group: Members
Posts: 305
Joined: 22-March 09
Member No.: 68263



QUOTE (eahm @ Mar 11 2013, 00:24) *
Also why the date is up to 2009 and not 2013?

Because nobody updated it tongue.gif


--------------------
Music: sounds arranged such that they construct feelings.
Go to the top of the page
+Quote Post
SpaceAgeHero
post Mar 11 2013, 08:57
Post #62





Group: Members
Posts: 116
Joined: 23-August 08
From: Berlin
Member No.: 57417



Will this new release support compressing multiple audio tracks / files simultaneously with multicore CPUs natively?
Go to the top of the page
+Quote Post
ktf
post Mar 11 2013, 10:10
Post #63





Group: Members
Posts: 305
Joined: 22-March 09
Member No.: 68263



QUOTE (SpaceAgeHero @ Mar 11 2013, 08:57) *
Will this new release support compressing multiple audio tracks / files simultaneously with multicore CPUs natively?

No, for features like that you should use other encoders.

This post has been edited by ktf: Mar 11 2013, 10:10


--------------------
Music: sounds arranged such that they construct feelings.
Go to the top of the page
+Quote Post
Maurits
post Mar 11 2013, 11:24
Post #64





Group: Members
Posts: 353
Joined: 30-September 05
From: London, Europe
Member No.: 24805



QUOTE (ktf @ Mar 11 2013, 10:10) *
QUOTE (SpaceAgeHero @ Mar 11 2013, 08:57) *
Will this new release support compressing multiple audio tracks / files simultaneously with multicore CPUs natively?

No, for features like that you should use other encoders.

I think that should be a feature for the frontend, not for the FLAC binary. Considering you can't use multiple cores to encode a single track it should be up to the frontend to just spawn multiple instances of the FLAC binary for each file and core.
Go to the top of the page
+Quote Post
lvqcl
post Mar 11 2013, 15:07
Post #65





Group: Developer
Posts: 3212
Joined: 2-December 07
Member No.: 49183



QUOTE (Maurits @ Mar 11 2013, 14:24) *
Considering you can't use multiple cores to encode a single track

Why? Afaik FLAC encoding is easy to parallelize.
Go to the top of the page
+Quote Post
skamp
post Mar 11 2013, 15:25
Post #66





Group: Developer
Posts: 1343
Joined: 4-May 04
From: France
Member No.: 13875



FLACCL, fpFLAC


--------------------
caudec.net
Go to the top of the page
+Quote Post
Maurits
post Mar 11 2013, 17:03
Post #67





Group: Members
Posts: 353
Joined: 30-September 05
From: London, Europe
Member No.: 24805



QUOTE (lvqcl @ Mar 11 2013, 15:07) *
QUOTE (Maurits @ Mar 11 2013, 14:24) *
Considering you can't use multiple cores to encode a single track

Why? Afaik FLAC encoding is easy to parallelize.


QUOTE (skamp @ Mar 11 2013, 15:25) *

You are of course both correct. How could I forget FLACCL...
Go to the top of the page
+Quote Post
ktf
post Mar 13 2013, 14:57
Post #68





Group: Members
Posts: 305
Joined: 22-March 09
Member No.: 68263



QUOTE (ktf @ Mar 6 2013, 20:45) *
QUOTE (C.R.Helmrich @ Mar 5 2013, 00:08) *
I'm just wondering whether 7- and 8-channel support is the only new feature for end users like me...

Aside from lots of bug fixes, cleanups and harderning, a few features were added.
- adding ReplayGain support for 88.2kHz, 96kHz, 176.4kHz and 192kHz files to metaflac
- while it was already present in FLAC 1.2.1, --ignore-chunk-sizes can be used to encode malformed WAV-files (i.e. > 4GB) and this option is now present in the documentation
- support for Wave64 and RIFF64 has been added

I think that's it, but I might have missed something. Here's the changelog: https://git.xiph.org/?p=flac.git;a=shortlog

Even more 'features': I just ran some of my 'lossless audio codec comparison' scripts, and it seems decoding has sped up a bit. Encoding is as fast as 1.2.1 and compression it the same too, as was already concluded here. More graphs see http://www.icer.nl/misc_stuff/FLAC-1.3.0-results.pdf



This post has been edited by ktf: Mar 13 2013, 15:00


--------------------
Music: sounds arranged such that they construct feelings.
Go to the top of the page
+Quote Post
romor
post Mar 13 2013, 15:13
Post #69





Group: Members
Posts: 650
Joined: 16-January 09
Member No.: 65630



That's quite a shift. Do you have a suspect?


--------------------
scripts: http://goo.gl/M1qVLQ
Go to the top of the page
+Quote Post
benski
post Mar 13 2013, 15:33
Post #70


Winamp Developer


Group: Developer
Posts: 669
Joined: 17-July 05
From: Ashburn, VA
Member No.: 23375



QUOTE (romor @ Mar 13 2013, 09:13) *
That's quite a shift. Do you have a suspect?


There were decoder optimizations done by Miroslav Lichvar. Specifically in the bitreader code in the Rice code decoder
Go to the top of the page
+Quote Post
romor
post Mar 13 2013, 15:47
Post #71





Group: Members
Posts: 650
Joined: 16-January 09
Member No.: 65630



Thanks @benski.
For reference this should be it: diff


--------------------
scripts: http://goo.gl/M1qVLQ
Go to the top of the page
+Quote Post
lvqcl
post Mar 14 2013, 17:53
Post #72





Group: Developer
Posts: 3212
Joined: 2-December 07
Member No.: 49183



Anybody knows how FLAC calculates MD5?

I took a 16-bit file and encoded it with FLAC, WavPack, TAK and OptimFrog. All encoders calculated MD5 = 00b0bff6862b518452b46ad994cbde11.
Then I converted it to a 24-bit file (padded with 8 zero bits). Again, all encoders agree on its checksum: 453f0af141959d709cccdc4723ff77ec.

So far so good. But then I changed wValidBitsPerSample field, and now FLAC disagrees with all other encoders.

CODE
valid_bits     WavPack, TAK, OptimFrog                 FLAC
16             453f0af141959d709cccdc4723ff77ec        00b0bff6862b518452b46ad994cbde11 (the same as for 16-bit file)
17             453f0af141959d709cccdc4723ff77ec        25234a864c084eb6c23c5f61ce5fdfc4
18             453f0af141959d709cccdc4723ff77ec        c207d52c70f3fda72595864f3d133f35
19             453f0af141959d709cccdc4723ff77ec        4b26f915fe3775ea165e58ba4fc4b1cd
20             453f0af141959d709cccdc4723ff77ec        daa325b376bfa803c849636fa1de0704
21             453f0af141959d709cccdc4723ff77ec        3d0670388b6919ab3ac79301b5c19996
22             453f0af141959d709cccdc4723ff77ec        cac12a2a39c14e20df4716f34ea145b7
23             453f0af141959d709cccdc4723ff77ec        086a82a505fac96241b50fd67c925f45
24             453f0af141959d709cccdc4723ff77ec        453f0af141959d709cccdc4723ff77ec (the same as in other encoders)

It seems that FLAC first shifts input PCM data by (BitsPerSample - ValidBitsPerSample) bits, and calculates MD5 of these altered data.
Go to the top of the page
+Quote Post
ktf
post Mar 14 2013, 18:05
Post #73





Group: Members
Posts: 305
Joined: 22-March 09
Member No.: 68263



QUOTE (lvqcl @ Mar 14 2013, 17:53) *
Anybody knows how FLAC calculates MD5?


Last time I checked, it was a MD5 sum of the raw data.

However, it seems FLAC is the only one displaying the right behaviour here, see http://msdn.microsoft.com/en-us/library/wi...v=vs.85%29.aspx The other encoders use all 24 bits to calculate the MD5 sum, presumably because they ignore wValidbitspersample and just encode all 24 bits. The specification however says wValidbitspersample is used to pack for example 20-bit audio in WAV (which can only be 24-bit or 16-bit, nothing in between AFAIK), so it seems FLAC just ignores the other bits while the other encoders keep them.

At least that would explain why your MD5sum for 16 bits is the same as the one of wValidbitspersample = 16 and why the MD5sums differ between FLAC and the other encoders


--------------------
Music: sounds arranged such that they construct feelings.
Go to the top of the page
+Quote Post
lvqcl
post Mar 14 2013, 18:27
Post #74





Group: Developer
Posts: 3212
Joined: 2-December 07
Member No.: 49183



When ValidBitsPerSample=16: yes, FLAC just throws away these padding bytes. But when ValidBitsPerSample=17...24 then FLAC doesn't discard bits but simply shifts all input samples by (BitsPerSample - ValidBitsPerSample) bits and only then calculates MD5.

I don't think that such behavior is better than the simple (and straightforward) algorithm of WavPack, TAK and OFR.

This post has been edited by lvqcl: Mar 14 2013, 18:29
Go to the top of the page
+Quote Post
ktf
post Mar 14 2013, 20:49
Post #75





Group: Members
Posts: 305
Joined: 22-March 09
Member No.: 68263



QUOTE (lvqcl @ Mar 14 2013, 18:27) *
When ValidBitsPerSample=16: yes, FLAC just throws away these padding bytes. But when ValidBitsPerSample=17...24 then FLAC doesn't discard bits but simply shifts all input samples by (BitsPerSample - ValidBitsPerSample) bits and only then calculates MD5.

Ah, sorry, I misunderstood/misread. Raw data of course can't be 22-bits or something like that, so indeed, MD5sum should be the same for 17 through 24 bits, as they are all packed as 24bit in raw audio. However, I don't understand why WavPack, TAK and OptimFrog can have the same MD5 for 16 bit and 24 bit. It would be stupid to pack 16-bit audio in a 24-bit container, true, but still, it looks like they just ignore wValidBitsPerSample?

Other news: The FLAC git has seen some changes on 2GB file limits on Windows. I didn't full understand the mailing list conversation, but apparently the limit was raised to 4GB and this can't be fixed until 1.3.1. Not really sure though. https://git.xiph.org/?p=flac.git;a=commit;h...ad983e3ec7fdb4f

This post has been edited by ktf: Mar 14 2013, 20:59


--------------------
Music: sounds arranged such that they construct feelings.
Go to the top of the page
+Quote Post

6 Pages V  < 1 2 3 4 5 > » 
Closed 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: 20th April 2014 - 00:32