IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
WavPack 4.70.0 alpha version available, bug fixes, transcoding and verify features
bryant
post Apr 2 2013, 20:08
Post #1


WavPack Developer


Group: Developer (Donating)
Posts: 1290
Joined: 3-January 02
From: San Francisco CA
Member No.: 900



I am in the process of completing the 4.70 release of WavPack and thought it would be a good time for an alpha (built with SVN 300) while I finish tweaking. The impetus for this release was to incorporate some bug fixes that had accumulated since 2009, but I decided to also include a few new features that I had been thinking about.

The most interesting new feature is the ability for the wavpack command-line executable to accept existing wavpack files as input (i.e., transcoding). This allows users to easily change the settings of files in their lossless collection. The process copies all tag information from the source, and even allows modification of the tags. Temp files are also used now when overwriting and a verify option has been added, so it's possible to safely do transcoding in-place (although this is an alpha version, so be careful!)

Note that care should be taken when transcoding to and from lossy files, and lossy to lossless transcoding is not allowed.

This release should generate identical files to the previous release (other than changes from bug fixes) and the performance should be similar (excepting differences from compiler revisions).

New features:
  • detect UTF-16LE encoding for tag text files (mostly a Windows thing)
  • use temporary files for safer overwriting
  • option to verify WavPack file integrity on creation (-v)
  • transcoding from existing WavPack files (with tag copy)
  • transition to Visual Studio 2008 (Windows)

Bug fixes:
  • seeking to last block failure (after finishing file)
  • memcpy() not always used correctly (Linux targets)
  • unsigned char issue (ARM targets)

Windows features ported to Linux:
  • clean handling of ^C
  • console title (with -z to defeat)
  • wildcards in tag specifications
  • 4GB file support on 32-bit OS

Windows 32-bit executables
Linux distro

Thanks in advance for any testing and/or suggestions! smile.gif
Go to the top of the page
+Quote Post
krafty
post Apr 2 2013, 20:29
Post #2





Group: Members
Posts: 274
Joined: 20-March 10
Member No.: 79175



Nice one Bryan!
Been waiting for this feature.

What about native tagging support? (Remember APEv2 1MB limit for art work?)
Go to the top of the page
+Quote Post
db1989
post Apr 2 2013, 20:32
Post #3





Group: Super Moderator
Posts: 5275
Joined: 23-June 06
Member No.: 32180



Are you referring only to artwork? Tagging has been supported for years. From the manual:
QUOTE
-w "Field=Value" = write specified metadata to APEv2 tag
Go to the top of the page
+Quote Post
larryfine
post Apr 2 2013, 21:22
Post #4





Group: Members
Posts: 57
Joined: 21-September 10
Member No.: 84040



Thank You, bryant!
I will test soon. I have several files of classical music waiting to compress.


--------------------
loquor mee menti: factus de materia, cinis elementi...
Go to the top of the page
+Quote Post
azaqiel
post Apr 2 2013, 23:39
Post #5





Group: Members
Posts: 24
Joined: 4-January 13
Member No.: 105572



I like this release, having jumped the gun and tested at r294 or so.

I believe krafty is referring to the inability to add an image (and possibly other binary files) greater than 1MB to the WavPack tags using the command-line program. for me this is a non-issue because I don't use album art, and foobar2000 supports adding >1MB binary files anyway.

I think a solution to this would be to max out the tag data at 16MB (2^24), either on a per-field basis or with all the fields added together. if people want ridiculously huge files in their tags, why not?
Go to the top of the page
+Quote Post
temp1
post Apr 3 2013, 02:05
Post #6





Group: Members
Posts: 17
Joined: 23-September 06
Member No.: 35512



good new,thank u, bryant.
i'll try it
Go to the top of the page
+Quote Post
krafty
post Apr 3 2013, 02:15
Post #7





Group: Members
Posts: 274
Joined: 20-March 10
Member No.: 79175



QUOTE
Are you referring only to artwork?


Yes. I think the issue is here:
http://www.hydrogenaudio.org/forums/index....st&p=697522
Go to the top of the page
+Quote Post
themanintheshado...
post Apr 3 2013, 09:09
Post #8





Group: Members
Posts: 28
Joined: 31-October 12
Member No.: 104212



Did a transcoding test of a WavPack file, and I didn't see any problems. The tags transferred over just fine, and both files (original & copy) passed MD5 and bit comparison tests in fb2k. The new verification feature also worked (It adds 1.5 to 2.0 seconds to the encoding process).
Go to the top of the page
+Quote Post
chi
post Apr 3 2013, 13:58
Post #9





Group: Members
Posts: 45
Joined: 27-November 11
Member No.: 95439



I think the pkg-config file is not correct. From wavpack.pc.in:
CODE
Libs: -L${libdir} -lwavpack @LIBM@ @ICONV@

However, iconv isn’t used in the library at all, only in the command-line tools. This means it should not be a linking requirement for libwavpack. The math library, on the other hand, is used by libwavpack, but its symbols are not part of the libwavpack API. This means it should go into Libs.private only (for static linking; see Guide to pkg-config).

In summary, the line should be replaced by these two:
CODE
Libs: -L${libdir} -lwavpack
Libs.private: @LIBM@
Go to the top of the page
+Quote Post
bryant
post Apr 3 2013, 18:50
Post #10


WavPack Developer


Group: Developer (Donating)
Posts: 1290
Joined: 3-January 02
From: San Francisco CA
Member No.: 900



QUOTE (krafty @ Apr 2 2013, 12:29) *
What about native tagging support? (Remember APEv2 1MB limit for art work?)
No, I haven't forgotten, but I keep going back and forth on this one.

I was thinking of adding a "--allow-huge-tags" option to allow embedding of up to 4 MB of tag data, with no single file over 1 MB. Would that be enough?
Go to the top of the page
+Quote Post
bryant
post Apr 3 2013, 19:04
Post #11


WavPack Developer


Group: Developer (Donating)
Posts: 1290
Joined: 3-January 02
From: San Francisco CA
Member No.: 900



QUOTE (chi @ Apr 3 2013, 05:58) *
In summary, the line should be replaced by these two:
CODE
Libs: -L${libdir} -lwavpack
Libs.private: @LIBM@

Thanks! I'll get this in...
Go to the top of the page
+Quote Post
krafty
post Apr 4 2013, 02:59
Post #12





Group: Members
Posts: 274
Joined: 20-March 10
Member No.: 79175



QUOTE
I was thinking of adding a "--allow-huge-tags" option to allow embedding of up to 4 MB of tag data, with no single file over 1 MB. Would that be enough?


That would still rely on APEv2 tags, right?
What I meant was a native tagging format like FLAC has.
Can VorbisComments be implemented into WavPack?
Sorry to sound pesky, I'm not really pesky about this. Any remedy is ok.
Go to the top of the page
+Quote Post
bryant
post Apr 4 2013, 04:53
Post #13


WavPack Developer


Group: Developer (Donating)
Posts: 1290
Joined: 3-January 02
From: San Francisco CA
Member No.: 900



QUOTE (krafty @ Apr 3 2013, 18:59) *
That would still rely on APEv2 tags, right?
What I meant was a native tagging format like FLAC has.
Can VorbisComments be implemented into WavPack?

Well I guess I'm confused then. I thought the problem was the desire to embed more than 1 MB of picture data into a WavPack file.

APEv2 tags are "native" to WavPack just like Vorbis comments are "native" to FLAC. Why would I want to implement Vorbis comments in WavPack? Doing that would break every program and device that supports WavPack files. Do Vorbis comments provide something important that APEv2 tags do not? The 1 MB limitation is something I have came up with to make the files more embedded-device friendly...it's not a APEv2 limitation (which actually specifies 8 KB as a limit).
Go to the top of the page
+Quote Post
krafty
post Apr 4 2013, 23:46
Post #14





Group: Members
Posts: 274
Joined: 20-March 10
Member No.: 79175



Sorry Bryant.
It was my misunderstanding.
Well can you just raise this to 2MB then?
It is just for the sake of embedding a large 1000px cover front, some of them are 1.5MB sometimes. Only sometimes.
Go to the top of the page
+Quote Post
db1989
post Apr 5 2013, 00:37
Post #15





Group: Super Moderator
Posts: 5275
Joined: 23-June 06
Member No.: 32180



I don’t mean that you shouldn’t have the ability, but where do requests like this end? Someone might want larger images and/or a different format, and thus want 3 MB, someone else 4… If anything, it seems that it would make more sense to remove the limit altogether than to raise it to another arbitrary threshold on the basis of one particular user and some of their files. This seems fair if a hard limit to size is not known and could be done with a disclaimer that users are responsible for any potential weird behaviour introduced by especially large embedded chunks of data.

Of course, there’s always the argument that files should be left external if full flexibility is desired… [/devilsadvocate] wink.gif
Go to the top of the page
+Quote Post
krafty
post Apr 5 2013, 16:38
Post #16





Group: Members
Posts: 274
Joined: 20-March 10
Member No.: 79175



Since I use mostly for lossless encodings, I think this limit should be removed. Lossless files are huge anyway, 2MB won't make a difference. Let alone images with 400MB, say 10MB of image data wouldn't hurt.
Perhaps maintaining it for lossy is ok.
Go to the top of the page
+Quote Post
db1989
post Apr 5 2013, 17:47
Post #17





Group: Super Moderator
Posts: 5275
Joined: 23-June 06
Member No.: 32180



FWIW, to me, an all or nothing approach seems most logical. If not, someone would probably eventually find a reason to want >1 MB in lossy files, then we’d be back here again. It seems like it would be more work to maintain different limits for the two encoding modes, which doesn’t seem worthwhile.

Of course, I don’t speak for David or his desires for his codec. But given that he already threw out Frank’s unforgiving limit of 8 kB, there’s no specified upper ceiling for the size of embedded chunks, so it seems like less work just to leave it open, and let users do what they want at their own risk, than it would be to decide upon a new limit.
Go to the top of the page
+Quote Post
greynol
post Apr 5 2013, 17:58
Post #18





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



It isn't like the source is closed.


--------------------
Placebophiles: put up or shut up!
Go to the top of the page
+Quote Post
bryant
post Apr 6 2013, 01:05
Post #19


WavPack Developer


Group: Developer (Donating)
Posts: 1290
Joined: 3-January 02
From: San Francisco CA
Member No.: 900



QUOTE (db1989 @ Apr 4 2013, 16:37) *
I don’t mean that you shouldn’t have the ability, but where do requests like this end? Someone might want larger images and/or a different format, and thus want 3 MB, someone else 4… If anything, it seems that it would make more sense to remove the limit altogether than to raise it to another arbitrary threshold on the basis of one particular user and some of their files. This seems fair if a hard limit to size is not known and could be done with a disclaimer that users are responsible for any potential weird behaviour introduced by especially large embedded chunks of data.

This makes sense. I'll attempt to read any tag I find. For writing, I'll add an option "--allow-huge-tags" that will raise the limit to some absurd size (like 16 MB) that disavows me of all responsibility.

Thanks, guys! smile.gif

Go to the top of the page
+Quote Post
Mr_Rabid_Teddybe...
post Apr 6 2013, 13:42
Post #20





Group: Members
Posts: 1197
Joined: 3-September 03
From: Bergen, Norway
Member No.: 8667



QUOTE (bryant @ Apr 5 2013, 17:05) *
This makes sense. I'll attempt to read any tag I find. For writing, I'll add an option "--allow-huge-tags" that will raise the limit to some absurd size (like 16 MB) that disavows me of all responsibility.


Why not only use a long-option something more like "--allow-absurdly-huge-tags-solely-on-your-own-responsibility-so-there" ....





--------------------
"ONLY THOSE WHO ATTEMPT THE IMPOSSIBLE WILL ACHIEVE THE ABSURD"
- Oceania Association of Autonomous Astronauts
Go to the top of the page
+Quote Post

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: 26th July 2014 - 10:23