Musepack is still as good as mp3 if not better and on par with modern codecs and vorbis and aac so why does no one talk about it? I was murking around the forum wiki and found out musepack was opensource which is a big plus for me... and older abx tests have it on par with aotuv or lame so why no talk? is it becuase of slow development? I think this is unfair if the codec is already so good no more tuning is needed..... any reason why people don't use mpc anymore other then compatibility? (converting from lossless to another format isn't too trivial... lol....)
I believe the answer is because MPC is on par with the modern codecs up in the "boring" bitrates >=160 VBR where all serious players are transparent a majority of the time for a majority of samples.
The public interest has shifted down to the fight for <=128 - where I have not noticed serious competition from MPC.
The public interest has shifted down to the fight for <=128 - where I have not noticed serious competition from MPC.
wow.... oh ok that sucks though I am willing to sacrifice disc space for transparency though... hard disk space is so cheap now a days.... but its not only about quality..... This codec being open source make it a major plus... but aoToV is another nice open source codec hough.. guess im going to have to just mess around with the both of them... I only encode anything below 170) (lame at vbr q4) for portable listening on my winmo... or when out and about on other pcs with a nice pair of head phones
I agree with Soap about the public being more interested in lower bitrates.
From personal tests i find Musepack to be a poor performer at low bitrates such as 96kbps - 128kbps, i even find --standard to be easy to ABX. At high bitrates such as 210 (Xtreme) it's very competitive.
From personal tests i find Musepack to be a poor performer at low bitrates such as 96kbps - 128kbps, i even find --standard to be easy to ABX. At high bitrates such as 210 (Xtreme) it's very competitive.
The point is hardware support.
If open source is big plus to you, i would recommend Ogg Vorbis; which offers better compatabilty then Musepack.
the future (present) of music on pc is lossless. on portable it's transparent and widespread (well supported) lossy (mp3 or occasionally aac, ogg). in long term, the future is lossless on portable too.
yes, there can be a few geeks using exotic codecs but the masses simply won't care coz the current solution (mp3 & flac) works and fits their needs.
yes, there can be a few geeks using exotic codecs but the masses simply won't care coz the current solution (mp3 & flac) works and fits their needs.
Well, it's a matter of choice, you know.
For me Musepack is a preferred codec for high quality music (for example progressive) because I believe it cause less listening fatigue. Or at least I believed that a few years ago. I cannot prove it because I doubt I could stay concentrated for few hours in order to do ABX or ABC tests. Maybe such tests are not feasible for long listening fatigue anyway.
For not so fussy stuff (because my HD space is not unlimited anyway) I use ogg vorbis, also an excellent codec using twice less space
.
For me Musepack is a preferred codec for high quality music (for example progressive) because I believe it cause less listening fatigue. Or at least I believed that a few years ago. I cannot prove it because I doubt I could stay concentrated for few hours in order to do ABX or ABC tests. Maybe such tests are not feasible for long listening fatigue anyway.
For not so fussy stuff (because my HD space is not unlimited anyway) I use ogg vorbis, also an excellent codec using twice less space
.
Years ago when HD space was an issue, high quality, high bitrate lossy mattered for the extreme minority who were concerned with transparency. The majority were fine with their 128kbps then and they are still now.
What is there to talk about anyway? Listening tests? With little to no development, what's the use? Hardware support?
What is there to talk about anyway? Listening tests? With little to no development, what's the use? Hardware support?
I disagree somewhat. The core values of HA sure has changed. I find it ironic that there is little interest in HQ lossy for portables and even PC - even using exotic formats. OTOH, lossless is encouraged and that is great as there is more HDD space these days. BUT: increased complexity is an issue ; Multiple libraries, obsessing with 128k or lower even though there is space for very high bitrate lossy or even lossless.
Major music stores are offering 256k audio. So that is the new '128 k'. Take a hint. We can go for 300 ~ 400k Vorbis / AAC , they have hardware support and this cuts lossless size in half and no transcoding.
Not everyone needs portable audio often so exotic stuff like wv hybrid, lossywav, mpc is also ok.
Major music stores are offering 256k audio. So that is the new '128 k'. Take a hint. We can go for 300 ~ 400k Vorbis / AAC , they have hardware support and this cuts lossless size in half and no transcoding.
Not everyone needs portable audio often so exotic stuff like wv hybrid, lossywav, mpc is also ok.
QUOTE (shadowking @ Aug 18 2009, 16:31) 
I disagree somewhat. The core values of HA sure has changed. I find it ironic that there is little interest in HQ lossy for portables and even PC - even using exotic formats.
Why is it ironic? I really doubt I could ABX 128k or above on a portable device that I listen too in noisy environments, or use as background music anyway.
QUOTE (shadowking @ Aug 18 2009, 16:31)
OTOH, lossless is encouraged and that is great as there is more HDD space these days. BUT: increased complexity is an issue ; Multiple libraries, obsessing with 128k or lower even though there is space for very high bitrate lossy or even lossless.
Lossless is more complex? Why? Who is obsessing about 128k?
QUOTE (shadowking @ Aug 18 2009, 16:31)
Major music stores are offering 256k audio. So that is the new '128 k'. Take a hint.
What is the hint, that I should base my behavior from a decision made by an internal committee of a corporate music store. A decision that I have no background information about why it was made in the first place?
QUOTE (shadowking @ Aug 18 2009, 16:31)
We can go for 300 ~ 400k Vorbis / AAC , they have hardware support and this cuts lossless size in half and no transcoding.
Well, I think vorbis support is still questionable (i.e. Sony, Apple, ...). I don't even know if it is supported by a base Windows install yet. You'll have to provide more evidence why you think 400k AAC is better than lossless, I just don't see it. As you said its only a 2x improvement over lossless, and HD are cheaps. And by definition, everything made from 400k AAC IS transcoded.
QUOTE (shadowking @ Aug 18 2009, 16:31)
Not everyone needs portable audio often so exotic stuff like wv hybrid, lossywav, mpc is also ok.
Not everyone, but I would say 90% or more are interested in portable audio. If not, then technically any format is fine. But I think it would be safer to choose something mainstream, or otherwise 10 years down the line you will be transcoding stuff. OTOH, if you pick a lossless format, you won't have to worry about transcoding across format changes ever.
128k is a reduction in standards. I am not telling anyone to NOT use it as that would be anti-freedom. This new mantra " just use lossless and stuff the other format cause mp3 is universal 128k should be fine" I find objectionable.
I like lossless , But shouldn't we be using it outside of our Pc as well ? I would like to take the same quality library everywhere i can. If HA members don't demand HQ playback DAP (gapless, lossless, exotic lossy..) - who will ?
I like lossless , But shouldn't we be using it outside of our Pc as well ? I would like to take the same quality library everywhere i can. If HA members don't demand HQ playback DAP (gapless, lossless, exotic lossy..) - who will ?
I think (or at least would hope) people want hq on a portable not for quality but for security... like e.g. I transcode a couple of albums for my winmo device I can easily just copy it back to a pc and have it sound practically transparent when using my home setup...
all the listening tests on this forum are done using 128k... and I know there are people that choose a codec based on those abx tests.... e.x. I went to foobar2000 irc channel and was told to use aac over vorbis because of abx (failed to find any tests though) quality tests at lower bitrates....
lol so why does everyone use mp3? for quality, compression? I believe for compatibility... but wait who decides what format is the standard of choice in hardware? an "internal committee" of people.... im not saying you use mp3 but its the "IT" codec now for alot people on this forum (from the polls) becuase of other peoples choices....
and to that person that recommended vorbis, I actually use aotuv 5.7 q6-8 for my "everyday playback" libary and compress to flac for my lossless
Removed unnecessary quote.
all the listening tests on this forum are done using 128k... and I know there are people that choose a codec based on those abx tests.... e.x. I went to foobar2000 irc channel and was told to use aac over vorbis because of abx (failed to find any tests though) quality tests at lower bitrates....
lol so why does everyone use mp3? for quality, compression? I believe for compatibility... but wait who decides what format is the standard of choice in hardware? an "internal committee" of people.... im not saying you use mp3 but its the "IT" codec now for alot people on this forum (from the polls) becuase of other peoples choices....
and to that person that recommended vorbis, I actually use aotuv 5.7 q6-8 for my "everyday playback" libary and compress to flac for my lossless
Removed unnecessary quote.
QUOTE (shadowking @ Aug 19 2009, 02:54)
I like lossless , But shouldn't we be using it outside of our Pc as well ? I would like to take the same quality library everywhere i can. If HA members don't demand HQ playback DAP (gapless, lossless, exotic lossy..) - who will ?
What does it mean to "take the same quality library everywhere I can"?
I can transcode my FLACs to MP3 upon transfer to my portable almost as fast as I can fill the portable's drive. I am pretty sure the next computer I buy will be able to transcode as fast as it can copy to a slow HDD. At that point what, exactly, is the advantage of not transcoding?
I do demand HQ playback on my DAP. I'm just not delusional enough to believe I can hear the difference between FLAC and LAME v3 on my DAP, and would rather have the battery life and size advantages of MP3.
QUOTE (viktor @ Aug 19 2009, 03:03)
the future (present) of music on pc is lossless. on portable it's transparent and widespread (well supported) lossy (mp3 or occasionally aac, ogg). in long term, the future is lossless on portable too...
I doubt the future is lossless because 1- lossless contain needless information 2- lower than lossless bitrates can give awfully good quality 3- songs sold online are mostly lossy and selling rythm is increasing fast (didn't some months ago digital albums sold surpassed traditional audio CD's selling?).
Besides, in the future desktops PC's will have market penetration as high as it has now? I think they will less and less important among all devices (existents and still to be developed).
QUOTE (nycjv321 @ Aug 19 2009, 13:09)
...
lol so why does everyone use mp3? for quality, compression? I believe for compatibility... but wait who decides what format is the standard of choice in hardware? an "internal committee" of people.... im not saying you use mp3 but its the "IT" codec now for alot people on this forum (from the polls) becuase of other peoples choices.
...
lol so why does everyone use mp3? for quality, compression? I believe for compatibility... but wait who decides what format is the standard of choice in hardware? an "internal committee" of people.... im not saying you use mp3 but its the "IT" codec now for alot people on this forum (from the polls) becuase of other peoples choices.
...
mp3 was one of the first codecs to get near transparancy at low bitrates and it was there at the right moment.
Several groups of people/companies/organizations/etc. developed a mp3 encoder causing mp3 to get popular fast, this in addition to internet starting to get into the homes. mpc/musepack didn't get much publicity nor hardware support nor vendor support.
QUOTE (shadowking @ Aug 19 2009, 08:54)
...
I like lossless , But shouldn't we be using it outside of our Pc as well ? I would like to take the same quality library everywhere i can. If HA members don't demand HQ playback DAP (gapless, lossless, exotic lossy..) - who will ?
I like lossless , But shouldn't we be using it outside of our Pc as well ? I would like to take the same quality library everywhere i can. If HA members don't demand HQ playback DAP (gapless, lossless, exotic lossy..) - who will ?
A kind of OT: Why this obsession with lossless format? (no offense
) Remember that lossless recording still is a lossy process. It's just about where one wants the limit. And the limit is influenced by all kind of factors.
I returned relatively recently to HA after quite a long time away, and I was surprised at the apparent change in attitude to MPC - from being *the* preferred lossy codec, it seems now to be almost treated with disdain by many here.
I think the "problem" (if you can call it that) is that it started from a very high level in terms of quality - this was certainly the reason I adopted it several years ago as my lossy codec of choice. From what I learnt from this forum, and from my own experiences, it was more or less "done" at an early stage in terms of perceptual transparency, apart from a handful of freak cases - any future sonic improvements would by definition be rare, subtle and undramatic, and I saw this as a benefit rather than a weakness.
I guess it was always likely that other codecs would eventually catch up, but IMHO that doesn't diminish Musepack's original achievement, or mean that it's in any way a "bad" lossy option today, unless you need certain features unrelated to perceptual transparency that other codecs can provide.
I think the "problem" (if you can call it that) is that it started from a very high level in terms of quality - this was certainly the reason I adopted it several years ago as my lossy codec of choice. From what I learnt from this forum, and from my own experiences, it was more or less "done" at an early stage in terms of perceptual transparency, apart from a handful of freak cases - any future sonic improvements would by definition be rare, subtle and undramatic, and I saw this as a benefit rather than a weakness.
I guess it was always likely that other codecs would eventually catch up, but IMHO that doesn't diminish Musepack's original achievement, or mean that it's in any way a "bad" lossy option today, unless you need certain features unrelated to perceptual transparency that other codecs can provide.
I think the world continued to be dominated by the iPod, while the things that weren't iPods started to play Vorbis and/or FLAC as well as mp3 (and usually WMA). MPC support didn't spread as fast.
If you want a lossy collection that is sure to outlive your current choice of DAP, mp3 has always been the only choice.
If you want a high quality collection on your PC, you've got more choice than ever, but rapidly diminishing disc prices make it increasingly silly not to use lossless.
I don't know if anyone else has noticed this, but CDs are heading towards obsolescence.
Now is a great time to make a lossless backup of your valuable collection. In five or ten years time, I don't think the tools are going to be so easily available - for instance, having an optical drive that can rip CDs quickly and securely won't be a huge selling point when most normal people have thrown their CDs in the bin! The time to rip to lossless is now (if you haven't already). 1.5TB HDD = £86 = about 3 pence per CD lossless.
As for what lossy to use, I'm with Soap:- it doesn't matter. Pick a fast encoder, leave some quality headroom, and do it on the fly.
Cheers,
David.
If you want a lossy collection that is sure to outlive your current choice of DAP, mp3 has always been the only choice.
If you want a high quality collection on your PC, you've got more choice than ever, but rapidly diminishing disc prices make it increasingly silly not to use lossless.
I don't know if anyone else has noticed this, but CDs are heading towards obsolescence.
Now is a great time to make a lossless backup of your valuable collection. In five or ten years time, I don't think the tools are going to be so easily available - for instance, having an optical drive that can rip CDs quickly and securely won't be a huge selling point when most normal people have thrown their CDs in the bin! The time to rip to lossless is now (if you haven't already). 1.5TB HDD = £86 = about 3 pence per CD lossless.As for what lossy to use, I'm with Soap:- it doesn't matter. Pick a fast encoder, leave some quality headroom, and do it on the fly.
Cheers,
David.
I have used Musepack for quite some time and of course it is still as good as it was, only many of the other lossy codecs have improved. LAME 3.98 -V 1 is for me a perfect alternative for Musepack -q 6 and plays virtually anywhere.
I felt Musepack has become a dead end street whereas FLAC (with or without lossywav) and mp3 have the better options for my use, now and the near future.
I felt Musepack has become a dead end street whereas FLAC (with or without lossywav) and mp3 have the better options for my use, now and the near future.
QUOTE (2Bdecided @ Aug 19 2009, 06:28)
I think the world continued to be dominated by the iPod, while the things that weren't iPods started to play Vorbis and/or FLAC as well as mp3 (and usually WMA). MPC support didn't spread as fast.
That is pretty much what I am thinking. Over the years, iPods have dominated the market selling millions of units in a single month. Additionally, the iTunes Store is selling millions of songs in a short period of time. That is a lot of growth for AAC support while mpc (and other formats such as OGG Vorbis) stays behind. It isn't mpc's fault but rather the market just went a different direction. We would be having a different conversation if Apple chose mpc as their format of choice over AAC.
For the lower bitrates (below 128kbps) musepack competes with aac, wma, and vorbis, all of which offer much better hardware and software support. That can't be denied, and that's pretty much the reason muspack is kind of pushed aside. If you like the openness of the codec, go vorbis...you have a much better chance of support than not. Anything above 128kbps is very much transparent across codecs so people go to the de-facto codecs (FLAC, ALAC, mp3, and aac) due to their support across many devices. Unless musepack can do all that, it can't be expected to be a modern player in the field.
I think Musepack is a perfectly usable format for many reasons:
- fast encoding
- fast decoding
- great quality at -q5
- APE tags
- notably smaller filesize at -q5 than LAME -V 2
- works on all the players I have
A quick bench on my machine (FB2K, buffer entire file to memory):
I benched the lossless codecs and only FLAC (at -5, btw) beat MPC with TAK coming close behind, and WAV reigning supreme, of course.
What I like is ripping the new CD's I bring home to MPC in record time and peruse the album at leisure keeping the CD safe and the disc drive unoccupied. If my collection is incompatible with people wanting free music... well, that's tough that I'm unpopular
- fast encoding
- fast decoding
- great quality at -q5
- APE tags
- notably smaller filesize at -q5 than LAME -V 2
- works on all the players I have
A quick bench on my machine (FB2K, buffer entire file to memory):
CODE
LAME MP3 = 171x
MPC SV8 = 272x
Vorbis = 161x
Nero AAC = 201x
MPC SV8 = 272x
Vorbis = 161x
Nero AAC = 201x
I benched the lossless codecs and only FLAC (at -5, btw) beat MPC with TAK coming close behind, and WAV reigning supreme, of course.
What I like is ripping the new CD's I bring home to MPC in record time and peruse the album at leisure keeping the CD safe and the disc drive unoccupied. If my collection is incompatible with people wanting free music... well, that's tough that I'm unpopular
QUOTE (nycjv321 @ Aug 19 2009, 01:08)
Musepack is still as good as mp3 if not better and on par with modern codecs and vorbis and aac so why does no one talk about it? I was murking around the forum wiki and found out musepack was opensource which is a big plus for me... and older abx tests have it on par with aotuv or lame so why no talk? is it becuase of slow development? I think this is unfair if the codec is already so good no more tuning is needed..... any reason why people don't use mpc anymore other then compatibility? (converting from lossless to another format isn't too trivial... lol....)
For starters, LAME is almost as good as MPC, and Vorbis can be said to be even better.
So, if LAME is on par with MPC, but it has 50 times the hw support, why bother with MPC?
And if you want better quality than LAME, why don't go with Vorbis wich still has much better HW support than MPC.
Or even more, go with FLAC.
Other problem i see is that for a long time, it was almost abandoned, and no new dev was being done.
This is how i see it.
QUOTE (Destroid @ Aug 20 2009, 00:25)
I think Musepack is a perfectly usable format for many reasons:
...
- works on all the players I have
...
- works on all the players I have
...at the moment.
Even then, what you've said might not be strictly true. Chances are you have something that plays mp3s but not mpcs (e.g. a DVD player) - you've just not thought to use it for that purpose.
Cheers,
David.
I think those who have a mpc music library and no current compatibility issue with players used don't have a real need actually to switch to another format. mpc at not too low a bitrate still is excellent. There seems to be not a significant amount of mpc development, but as the codec is mature, there is also no real need for that though it would be welcome.
For all those who don't have a mpc music library actually mpc isn't a good choice. Qualitywise AAC, Vorbis and even today's mp3 are a good alternative with better hardware compatibility (with AAC getting more and more DAP support and Vorbis falling a bit behind).
For all those who don't have a mpc music library actually mpc isn't a good choice. Qualitywise AAC, Vorbis and even today's mp3 are a good alternative with better hardware compatibility (with AAC getting more and more DAP support and Vorbis falling a bit behind).
QUOTE (halb27 @ Aug 20 2009, 12:06)
I think those who have a mpc music library and no current compatibility issue with players used don't have a real need actually to switch to another format.
They do - they need to re-rip to lossless while they still can. If they wait until the next new DAP/car/phone/whatever they want to buy doesn't have MPC support, they might find they don't have the time / hardware / CDs left to re-rip then!Assuming the people who ripped entire collections to MPC originally are the kind who care about audio quality and technology - these are the very people that are going to find being stuck with MPC a serious inconvenience first.
People who don't care about technology might keep listening on the same old devices. People who don't care about audio quality could just transcode MPC to mp3. But I don't think such people used MPC in the first place. I could be wrong.
Cheers,
David.
QUOTE (Soap @ Aug 19 2009, 03:16)
The public interest has shifted down to the fight for <=128 - where I have not noticed serious competition from MPC.
Mainly because nowadays the music is listened in noisy environment and as a background (DAPs, USB car players, streaming to mobile phones etc.), I believe.
QUOTE (/mnt @ Aug 19 2009, 03:29)
From personal tests i find Musepack to be a poor performer at low bitrates such as 96kbps - 128kbps, i even find --standard to be easy to ABX. At high bitrates such as 210 (Xtreme) it's very competitive.
Musepack has never been optimized for low/midrange bitrates, IIRC.
QUOTE (twostar @ Aug 19 2009, 04:38)
What is there to talk about anyway? Listening tests? With little to no development, what's the use?
QUOTE (kwanbis @ Aug 20 2009, 07:18)
Other problem i see is that for a long time, it was almost abandoned, and no new dev was being done.
This is how i see it.
This is how i see it.
Little to no development? How would you comment this:
CODE
08/04/09:
22:11 Changeset [452] by r2d
*
libmpc/trunk/mpcenc/config.h
* …
libmpc (mpcenc) : * improved file extension conversion to .mpc * version …
08/03/09:
12:51 Changeset [451] by r2d
*
libmpc/trunk/CMakeLists.txt
libmpc : * shared option default to on, unless on windows
12:44 Changeset [450] by r2d
*
libmpc/trunk/CMakeLists.txt
* …
libmpc (patch by Samuli Suominen) : * add install target for cmake * add …
07/31/09:
15:38 Changeset [449] by r2d
*
libmpc/trunk/libmpcdec/mpcdec_math.h
libmpc : * typo
15:37 Changeset [448] by r2d
*
libmpc/trunk/include/mpc/mpcmath.h
* …
libmpc : * moved math.h include in mpcmath.h
15:03 Changeset [447] by r2d
*
libreplaygain/src/CMakeLists.txt
libreplaygain : * cmake improvement
14:58 Changeset [446] by r2d
*
libcuefile/trunk/src/CMakeLists.txt
libcuefile : * add a shared library target to cmake * add install target …
07/30/09:
00:00 Changeset [445] by r2d
*
libmpc/trunk/Makefile.am
* …
* autotool changes to support symbol visibility on MinGW. * mpcchap build …
06/24/09:
23:45 Changeset [444] by r2d
*
libmpc/trunk/mpcdec/mpcdec.c
patch by Dr. Fiemost : fixed an error when building mpcdec on MinGW since …
23:22 Changeset [443] by r2d
*
libmpc/trunk/common/crc32.c
* …
renamed crc32 to mpc_crc32 to avoid name conflics with static libs
03/31/09:
14:24 Changeset [442] by Seed
*
libmpc/trunk/mpcgain/mpcgain.c
14:23 Changeset [441] by Seed
*
libmpc/trunk/win32/mpcgain.vcproj
a fix to allow wildcards
03/30/09:
01:01 Changeset [440] by r2d
*
libmpc/trunk/mpcgain/mpcgain.c
mpcgain bug correction : open files in binary mode (changed version …
03/17/09:
16:59 Changeset [439] by grimmel
*
libmpc/trunk/libmpcdec/mpc_demux.c
More fixes from DEATH
03/08/09:
13:56 Changeset [438] by radscorpion
*
dsfilters/dec_mpc/bin/mmmpcdec.ax
* …
Fixes for SV7 seeking. Rebuilt with latest libraries
12:59 Changeset [437] by radscorpion
*
libmpc/trunk/win32/libcommon_2005.vcproj
* …
Added VS2005 projects for libcommon / libmpcdec with MFC Static (needed …
03/07/09:
12:42 Changeset [436] by r2d
*
libmpc/trunk/libmpcdec/internal.h
* …
mpccut should now be more resilient to errors
02/26/09:
20:41 Changeset [435] by r2d
*
libmpc/trunk/mpcenc/config.h
* …
- Added a special case to ignore --xlevel and --noxlevel options - Changed …
02/24/09:
20:10 Changeset [434] by r2d
*
libmpc/trunk/libmpcdec/ChangeLog
spelling fix
05:15 SV8Specification edited by shy
(diff)
05:05 SV8Build edited by shy
grammar (diff)
04:50 WikiStart edited by shy
(diff)
04:48 WikiStart edited by shy
(diff)
02/23/09:
21:14 Changeset [433] by r2d
*
libmpc/trunk/libmpcdec/ChangeLog
* …
- change libmpcdec API version (libtool) - update ChangeLog and README
20:45 Changeset [432] by r2d
*
libmpc/trunk/mpcdec/mpcdec.c
mpcdec update copyright and version to 1.0.0 for sv8 release
20:44 Changeset [431] by r2d
*
libmpc/trunk/include/mpc/mpc_types.h
* …
update copyright (2nd part)
20:42 Changeset [430] by r2d
*
libmpc/trunk/mpc2sv8/mpc2sv8.c
change mpc2sv8 version to 1.0.0 for sv8 release
20:40 Changeset [429] by r2d
*
libmpc/trunk/mpcchap/mpcchap.c
add version information to mpcchap
20:36 Changeset [428] by r2d
*
libmpc/trunk/mpcgain/mpcgain.c
mpcgain supports chapters : change version
20:15 Changeset [427] by r2d
*
libmpc/trunk/libmpcenc/analy_filter.c
* …
update copyright
02/18/09:
23:09 Changeset [426] by r2d
*
libmpc/trunk/libmpcdec/streaminfo.c
copied too fast
correction for max_band upper bound (thanks DEATH for … 02/16/09:
22:33 Changeset [425] by r2d
*
libmpc/trunk/libmpcdec/mpc_demux.c
* …
check streaminfo values
02/12/09:
22:54 Changeset [424] by r2d
*
libmpc/trunk/libmpcdec/mpc_bits_reader.c
* …
check block size & changed inline for mpc_inline, MSVC seems to accept …
02/11/09:
23:41 Changeset [423] by r2d
*
libmpc/trunk/libmpcdec/mpc_demux.c
improves chapter parsing resilience to errors
17:23 Changeset [422] by grimmel
*
libmpc/trunk/win32/libcommon.vcproj
* …
01/18/09:
18:17 Changeset [421] by radscorpion
*
dsfilters/demux_mpc/bin/mmmpcdmx.ax
* …
Demuxer updated to 0.4.0.0 Support for APE 2.0 tags Chapters are now …
13:07 Changeset [420] by radscorpion
*
dsfilters/dec_mpc/bin/mmmpcdec.ax
* …
DirectShow Musepack Decoder updated to 0.9.2.0 Bug fixed with -6 dB …
01/16/09:
19:47 SV8Specification edited by r2d
(diff)
00:49 SV8Specification edited by shy
minor mistypes fixed (diff)
12/10/08:
23:42 SV8Build created by r2d
22:46 WikiStart edited by r2d
(diff)
11/12/08:
20:15 Changeset [419] by r2d
*
libmpc/trunk/include/mpc/mpcdec.h
* …
- changed version string to 1.28.0 - added const to mpc_demux_chap return …
20:06 SV8Specification edited by r2d
(diff)
11/02/08:
14:05 Changeset [418] by r2d
*
libmpc/trunk/mpcchap/CMakeLists.txt
libmpc cmake uses libcuefile from svn
14:03 Changeset [417] by r2d
*
libcuefile/trunk/src/cuefile.c
libcuefile builds with msvc
13:37 Changeset [416] by r2d
*
libcuefile/trunk/CMakeLists.txt
* …
moved files, added cmake build system
13:01 Changeset [415] by r2d
*
libcuefile
* …
libcuefile initial import from cuetools 1.3.1
01:21 Changeset [414] by r2d
*
libmpc/trunk/common/tags.c
* …
changes to make mpcchap build with msvc
11/01/08:
22:09 Changeset [413] by r2d
*
libmpc/trunk/libmpcdec/mpc_bits_reader.h
* …
updated mpcgain to fill the chapters' gain / peak
22:01 Changeset [412] by r2d
*
libreplaygain/include/replaygain/gain_analysis.h
* …
libreplaygain can now handle chapters
10/31/08:
00:20 Changeset [411] by r2d
*
libmpc/trunk/include/mpc/mpcdec.h
* …
added chapter gain / peak to libmpcdec and mpcchap as in the spec
10/06/08:
20:30 Changeset [410] by r2d
*
libmpc/trunk/configure.in
* …
fix cross-compilation with mingw (patch by Leandro Nini)
20:26 Changeset [409] by r2d
*
libmpc/trunk/libmpcdec/Makefile.am
* …
installable headers cleanup (patch by Leandro Nini)
09/18/08:
22:39 SV8Specification edited by r2d
chapter replay gain proposition (diff)
08/12/08:
23:46 Changeset [408] by r2d
*
libmpc/trunk/mpcchap/Makefile.am
* …
removed my local file path (patch by xmixahlx)
06/02/08:
16:23 Changeset [407] by r2d
*
libmpc/trunk/libmpcdec/mpc_demux.c
added a bound to the seek table size, varying the step between seek points …
05/01/08:
22:46 Changeset [406] by r2d
*
libmpc/trunk/mpcchap/mpcchap.c
mpcchap overflow correction
19:04 Changeset [405] by r2d
*
libmpc/trunk/libmpcdec/mpc_demux.c
changed declaration to conform to C89
04/25/08:
17:05 Changeset [404] by r2d
*
libmpc/trunk/mpcgain/mpcgain.c
updated mpcgain according to libreplaygain new functions name
17:03 Changeset [403] by r2d
*
libreplaygain/include/replaygain/gain_analysis.h
* …
- reduced libreplaygain symbol exports - prefixed API function names with …
04/24/08:
13:06 Changeset [402] by r2d
*
libmpc/trunk/include/mpc/mpcdec.h
* …
moved mpc_bits_reader definition in mpcdec.h for use in the API
04/21/08:
16:34 Changeset [401] by r2d
*
libmpc/trunk/include/mpc/mpc_types.h
correction for non GCC compilers
16:22 Changeset [400] by r2d
*
libmpc/trunk/include/mpc/mpc_types.h
* …
Limited libmpcdec exported symbols (only for autotools building because …
04/13/08:
23:15 Changeset [399] by radscorpion
*
dsfilters/temp/libmpcenc/include/libmpcenc.h
* …
further encoder library updates. added demo app for the new libmpcenc.
19:00 Changeset [398] by radscorpion
*
dsfilters/temp/libmpcenc/include/libmpcenc.h
* …
interface extended for the encoder. rewritten bitstream output system for …
15:06 Changeset [397] by radscorpion
*
dsfilters/temp/libmpcenc/include/libmpcenc.h
* …
libmpcpsy should be complete added basic VC++ project
04/11/08:
14:11 Changeset [396] by radscorpion
*
dsfilters/temp/libmpcenc/src/fft4g.c
* …
som more cleanups…
00:29 Changeset [395] by radscorpion
*
dsfilters/temp
* …
Added temporary dir with new cleaner encoding library. Library interface …
04/06/08:
16:19 Changeset [394] by r2d
*
libmpc/trunk/mpcchap/CMakeLists.txt
* …
mpcchap supports cue/toc files through cuetools library (CMakeLists.txt …
04/05/08:
23:41 Changeset [393] by r2d
*
libmpc/trunk/mpcchap/iniparser.c
* …
added commentary to added iniparser functions
20:34 Changeset [392] by r2d
*
xmms-musepack/branches/r2d/Makefile.in
* …
removed autoconf generated files from the repository
20:33 Changeset [391] by r2d
*
xmms-musepack/branches/r2d/src/libmpc.cpp
* …
xmms-musepack cleanup
20:09 Changeset [390] by r2d
*
libmpc/trunk/include/mpc/mpcdec.h
* …
libmpcdec API cleanup and documentation
04/02/08:
17:30 SV8Specification edited by r2d
(diff)
17:22 Changeset [389] by r2d
*
libmpc/trunk/libmpcdec/mpc_demux.c
- libmpcdec can now find chapters in files without seek table
16:01 Changeset [388] by r2d
*
libmpc/trunk/mpcchap/mpcchap.c
- chapters are now able to contain no tag
04/01/08:
23:04 Changeset [387] by r2d
*
libmpc/trunk/mpcchap/iniparser.c
* …
- mpcchap can now dump chapters
03/29/08:
21:23 Changeset [386] by r2d
*
libmpc/trunk/CMakeLists.txt
fixed cmake file for mpcchap
20:56 Changeset [385] by r2d
*
libmpc/trunk/common/tags.c
* …
- added CMakeLists.txt for mpcchap (untested) - corrected mpcenc …
03/25/08:
16:31 Changeset [384] by r2d
*
libmpc/trunk/Makefile.am
* …
- added mpcchap utility to add (and later dump) chapters in a sv8 mpc file …
03/19/08:
19:16 Changeset [383] by r2d
*
libmpc/trunk/libmpcdec/mpc_decoder.c
removed EQ_TAP, DELAY and FIR_BANDS as suggested by Andree Bushmann
03/06/08:
16:39 Changeset [382] by r2d
*
libmpc/trunk/libmpcdec/huffman.h
* …
made some const changes
01/13/08:
19:23 Changeset [381] by radscorpion
*
dsfilters/dec_mpc/bin/mmmpcdec.ax
* …
Recompiled with MFC as Static
01/06/08:
01:03 SV8Specification edited by r2d
removed chapter number (diff)
01/05/08:
20:49 Changeset [380] by radscorpion
*
dsfilters/dec_mpc/bin/mmmpcdec.ax
* …
Fixed SV7 seeking artifacts. Fixed gain info.
11:40 Changeset [379] by radscorpion
*
dsfilters/before-you-ask.txt
* …
SV7 demuxing and decoding works. However there are strange artifacts when …
01/04/08:
13:54 SV8Specification edited by r2d
added status for the document (diff)
13:42 final.png attached to SV8Specification by r2d
13:41 beta.png attached to SV8Specification by r2d
13:40 alpha.png attached to SV8Specification by r2d
13:07 SV8Specification edited by r2d
(diff)
11:57 SV8Specification edited by r2d
added Chapter packet (diff)
10:45 SV8Specification edited by r2d
added links to packets (diff)
01/03/08:
23:50 Changeset [378] by radscorpion
*
dsfilters/demux_mpc/demux_mpc.suo
* …
Basic SV7 parsing. TODO: Construct seeking table. !!! WARNING !!! If you …
12/20/07:
23:28 Changeset [377] by r2d
*
libmpc/trunk/libmpcdec/mpc_demux.c
corrected a bug that prevented the scalefactors to be reset on seeking …
12/18/07:
23:55 Changeset [376] by r2d
*
libmpc/trunk/include/mpc/mpc_types.h
* …
added LONG_SEEK_TABLE define for a 64 bits long offset in the seek table …
12/15/07:
21:20 Changeset [375] by radscorpion
*
dsfilters/demux_mpc/bin/mmmpcdmx.ax
* …
Redesigned property page. Fixed loop-seeking. Added version info for …
21:04 Changeset [374] by radscorpion
*
dsfilters/dec_mpc/bin/mmmpcdec.ax
* …
Eye candy property page for the decoder filter.
19:09 Changeset [373] by radscorpion
*
dsfilters/dec_mpc/bin/mmmpcdec.ax
* …
Fixed seeking.
17:04 Changeset [372] by radscorpion
*
dsfilters/dec_mpc/bin/mmmpcdec.ax
* …
Seeking fixes. Splitter now registers mediatypes
14:49 Changeset [371] by radscorpion
*
dsfilters/before-you-ask.txt
* …
Decoder now can decode and play SV8 streams. It can be used along with old …
12/14/07:
21:29 Changeset [370] by radscorpion
*
dsfilters/dec_mpc/bin/mmmpcdec.ax
* …
Okay. It can now connect. Sound should be done tomorrow.
19:48 Changeset [369] by radscorpion
*
dsfilters/before-you-ask.txt
* …
Basis for decoder filter. It cannot be created right now. I's just a …
00:22 Changeset [368] by radscorpion
*
dsfilters/before-you-ask.txt
* …
MPC Demux works. Right now it can only be used with Dump filter, because …
12/13/07:
19:24 Changeset [367] by radscorpion
*
dsfilters/demux_mpc/src/bits.cpp
* …
added a few methods to parse seek table offset and seek table. Golomb …
12:40 SV8Specification edited by r2d
removed definitely end silence (diff)
12/12/07:
20:09 Changeset [366] by radscorpion
*
dsfilters/before-you-ask.txt
* …
First build of splitter filter.
12/11/07:
22:21 Changeset [365] by radscorpion
*
dsfilters
* …
Created basic directory structure for DirectShow filters.
12/01/07:
18:46 Changeset [364] by r2d
*
libmpc/trunk/mpcdec/mpcdec.c
stdin/stdout set to binary under windows
11/23/07:
17:39 Changeset [363] by r2d
*
libmpc/trunk/mpc2sv8/mpc2sv8.c
* …
- corrections to compile with msvc c (c89?) - removed headers from other …
11/10/07:
12:45 Changeset [362] by r2d
*
libmpc/trunk/mpc2sv8/CMakeLists.txt
* …
- added basename and dirent implementation for win32 - updated mpc2sv8 …
10/21/07:
14:29 Changeset [361] by r2d
*
xmms-musepack/branches/r2d/src/libmpc.cpp
* …
correction for mono files
14:27 Changeset [360] by r2d
*
libmpc/trunk/libmpcdec/internal.h
* …
correction for mono files
10/02/07:
12:20 Changeset [359] by r2d
*
libmpc/trunk/include/mpc/mpc_types.h
* …
changed mpc_quantizer size
11:42 Changeset [358] by r2d
*
libmpc/trunk/libmpcdec/mpc_demux.c
SV7 seeking bug correction when header not aligned on 4 bytes
10/01/07:
18:54 Changeset [357] by r2d
*
libmpc/trunk/mpc2sv8/mpc2sv8.c
- mpc2sv8 can overwrite output (option -o) - mpc2sv8 can output to a …
09/27/07:
12:54 Changeset [356] by r2d
*
libmpc/trunk/mpcdec/mpcdec.c
added pipe input and output for mpcdec
12:18 Changeset [355] by r2d
*
libmpc/trunk/libmpcdec/mpc_demux.c
- correction of the id3v2 tag seeking bug
11:44 Changeset [354] by r2d
*
libmpc/tags/1.27.0-beta-1
Tag for the first beta of sv8 tools
09/23/07:
22:09 Changeset [353] by r2d
*
libmpc/trunk/mpc2sv8/mpc2sv8.c
* …
changed copyright info
20:48 Changeset [352] by r2d
*
libmpc/trunk/mpcenc/config.h
changed mpcenc version because of bug correction
20:41 Changeset [351] by zorg
*
libmpc/trunk/libmpcpsy/psy_tab.c
fix compilation under mingw
19:20 Changeset [350] by r2d
*
libmpc/trunk/libmpcdec/streaminfo.c
replay gain changes again ... last change was not correct
19:12 Changeset [349] by r2d
*
libmpc/trunk/include/mpc/mpcmath.h
* …
corrected error with optimized gcc builds and CVD_FASTLOG defined
18:38 Changeset [348] by r2d
*
libmpc/trunk/mpcenc/mpcenc.c
changed help according to 1.16 version
18:17 Changeset [347] by r2d
*
libmpc/trunk/libmpcdec/streaminfo.c
changed replay gain rounding and reference
09/19/07:
21:33 Changeset [346] by zorg
*
libmpc/trunk/win32/libcommon.vcproj
* …
add missing vcproj for mpcgain fix build on win32 patch by DEATH
21:25 Changeset [345] by zorg
*
libreplaygain/libreplaygain.vcproj
add vcproj for msvc2005. patch by DEATH
09/17/07:
18:41 Changeset [344] by r2d
*
libmpc/trunk/mpcdec/mpcdec.c
* …
added version info for mpcdec and mpcgain
09/09/07:
18:17 Changeset [343] by r2d
*
libmpc/trunk/win32/libmpcenc.vcproj
* …
updated MSVC8 project files, patch by DEATH
08/20/07:
22:37 Changeset [342] by r2d
*
libmpc/trunk/libmpcdec/mpc_bits_reader.h
made changes so msvc doesn't complain, changes doesn't affects gcc speed …
07/29/07:
19:20 Changeset [341] by r2d
*
libmpc/trunk/libmpcdec/mpc_demux.c
skip error detection if it's end of stream
07/22/07:
16:42 Changeset [340] by r2d
*
libmpc/trunk/libmpcpsy/cvd.c
* …
corrections for windows build
06/30/07:
20:18 Changeset [339] by r2d
*
libmpc/trunk/mpcdec/mpcdec.c
added check stream option to mpcdec
13:45 Changeset [338] by r2d
*
libmpc/trunk/libmpcdec/mpc_bits_reader.h
added explicit cast
06/27/07:
20:00 Changeset [337] by r2d
*
libmpc/trunk/libmpcdec/mpc_demux.c
make aligned swaping in buffer (alignement on buffer start, there is no …
06/09/07:
21:34 Changeset [336] by zorg
*
libmpc/trunk/win32/mpcenc.vcproj
missing defines
21:06 Changeset [335] by zorg
*
libmpc/trunk/win32/libmpcpsy.vcproj
Add fastmath
19:26 Changeset [334] by zorg
*
libmpc/trunk/CMakeLists.txt
* …
Update cmake
17:43 Changeset [333] by r2d
*
libmpc/trunk/common/fastmath.c
* …
put back FAST_MATH stuff, don't forget to define FAST_MATH and CVD_FASTLOG …
06/08/07:
17:20 Changeset [332] by zorg
*
libmpc/trunk/mpccut/CMakeLists.txt
* …
Enforce C projects
01:19 Changeset [331] by zorg
*
libmpc/trunk/win32/libcommon.vcproj
* …
misc
00:28 Changeset [330] by zorg
*
libmpc/trunk/win32/mpc2sv8.sln
* …
misc
00:11 Changeset [329] by zorg
*
libmpc/trunk/win32/libcommon.vcproj
* …
misc
06/07/07:
23:55 Changeset [328] by zorg
*
libmpc/trunk/mpcdec/mpcdec.c
Fix broken args check
23:54 Changeset [327] by zorg
*
libmpc/trunk/libmpcpsy/cvd.c
Add missing header
05/27/07:
18:04 SV8Specification edited by r2d
(diff)
17:54 SV8Specification edited by r2d
(diff)
16:36 Changeset [326] by r2d
*
libmpc/trunk/mpcenc/mpcenc.c
removed OSS input in help
05/25/07:
17:37 SV7FrameDecoding edited by r2d
(diff)
17:36 SV7FrameDecoding edited by r2d
(diff)
17:29 SV7FrameDecoding edited by r2d
(diff)
17:25 SV7FrameDecoding created by r2d
16:55 SV7Specification edited by r2d
(diff)
05/13/07:
15:47 Changeset [325] by r2d
*
libmpc/trunk/mpcenc/mpcenc.c
corrected end of file
05/12/07:
23:45 Changeset [324] by r2d
*
winamp-musepack/trunk/in_mpc.cpp
file is closed after function call
12:43 Changeset [323] by r2d
*
libmpc/trunk/mpcdec/mpcdec.c
* …
- Corrected end of loop condition when encoded file doesn't report correct …
05/11/07:
14:08 Changeset [322] by r2d
*
winamp-musepack/trunk/in_mpc.cpp
* …
Added winamp extended info (replay gain and title formating)
11:46 Changeset [321] by r2d
*
libmpc/trunk/mpccut/mpccut.c
bug correction for mpccut (bad decoded sample number)
05/10/07:
16:34 Changeset [320] by r2d
*
libmpc/trunk/CMakeLists.txt
* …
updated Windows/CMake build
16:02 Changeset [319] by r2d
*
libmpc/trunk/win32/attgetopt.c
* …
added getopt function for win32
15:58 Changeset [318] by r2d
*
libmpc/trunk/mpccut/mpccut.c
* …
Use getopt.h
13:01 Changeset [317] by r2d
*
libmpc/trunk/Makefile.am
* …
Added mpccut prog, sv8 files can now be cutted
00:25 Changeset [316] by r2d
*
libmpc/trunk/mpcdec/mpcdec.c
Added old gain view
00:01 Changeset [315] by r2d
*
libmpc/trunk/mpcdec/mpcdec.c
Added -i flag to print file information
05/09/07:
23:11 Changeset [314] by r2d
*
libmpc/trunk/libmpcdec/mpc_decoder.c
* …
Added support for beg_silence (no yet tested as can't make files that use …
23:07 Changeset [313] by r2d
*
xmms-musepack/branches/r2d/src/libmpc.cpp
Added sample number in file info
18:24 Changeset [312] by r2d
*
libmpc/trunk/libmpcenc/bitstream.c
Bug correction, please re-test encoding through pipe
14:52 Changeset [311] by r2d
*
libmpc/trunk/include/mpc/streaminfo.h
* …
Removed end_silence to comply with spec
05/07/07:
23:51 SV8Specification edited by r2d
End silence is redundant with sample count (diff)
05/04/07:
14:10 Changeset [310] by r2d
*
libmpc/trunk/libmpcdec/mpc_bits_reader.h
* …
- corrected a M/S bug in sv8 decoding - changed Max_used_band usage in sv7 …
05/03/07:
14:42 Changeset [309] by r2d
*
libmpc/trunk/mpc2sv8/mpc2sv8.c
added error reporting to mpc2sv8
14:21 Changeset [308] by r2d
*
libmpc/trunk/mpcenc/config.h
updated mpcenc version
12:39 Changeset [307] by r2d
*
libmpc/trunk/libmpcenc/bitstream.c
* …
writeBits can't output more than 31 bits !
00:05 Changeset [306] by r2d
*
libmpc/trunk/libmpcdec/mpc_demux.c
removed a check that may fail on a valid file
05/02/07:
23:20 Changeset [305] by r2d
*
libmpc/trunk/libmpcdec/mpc_demux.c
forgot to remove debug code
22:55 Changeset [304] by zorg
*
libmpc/trunk/libmpcpsy/fft_routines.c
Simplify code by using array notation. It should also make the task easier …
22:47 Changeset [303] by zorg
*
libmpc/trunk/libmpcpsy/psy.c
Factorize some operations out of the inner loop
22:31 Changeset [302] by r2d
*
libmpc/trunk/libmpcdec/mpc_demux.c
* …
- added some checks in sv8 demuxing - corrected a bug in mpc2sv8
04/27/07:
22:37 Changeset [301] by r2d
*
libmpc/trunk/libmpcdec/mpc_decoder.c
* …
corrected a bug when seeking after the last frame as been decoded
22:35 Changeset [300] by r2d
*
libmpc/trunk/include/mpc/mpc_types.h
correction : needed even in floating point
12:50 Changeset [299] by r2d
*
libmpc/trunk/include/mpc/mpc_types.h
* …
- moved some MPC_FIXED_POINT defines from mpcdec_math.h to mpc_types.h - …
04/26/07:
22:36 Changeset [298] by r2d
*
libmpc/trunk/libmpcdec/streaminfo.c
changed encoder description for sv7 encoder in sv8 stream
21:11 Changeset [297] by r2d
*
libmpc/trunk/mpc2sv8/mpc2sv8.c
corrected gain information conversion bug
04/24/07:
15:07 Changeset [296] by r2d
*
libmpc/trunk/libmpcdec/huffman.c
* …
Improved sv8 huffman decoding using canonical property of the huffman …
04/23/07:
21:30 Changeset [295] by r2d
*
libmpc/trunk/libwavformat/input.c
* …
removed aliasing warnings
18:35 Changeset [294] by r2d
*
libmpc/trunk/CMakeLists.txt
* …
finished branch move
18:23 Changeset [293] by r2d
*
libmpc/trunk/r2d
moving branche to trunk
16:59 Changeset [292] by r2d
*
xmms-musepack/branches/r2d/src/libmpc.cpp
updated according to libmpcdec
16:58 Changeset [291] by r2d
*
libmpc/branches/r2d/include/mpc/mpcdec.h
* …
changed function name to match other functions naming convention
16:47 Changeset [290] by r2d
*
libmpc/branches/r2d/libmpcdec/huffman.c
* …
improved decoder speed using LUT for huffman decoding. profiling/bench …
00:44 Changeset [289] by zorg
*
libmpcdec/trunk/configure.ac
Replace memcmp configure check with a supposedly better one
04/22/07:
15:43 Changeset [288] by r2d
*
libmpc/branches/r2d/libmpcdec/huffman.c
* …
made huffman tables smaller
04/21/07:
20:59 Ticket #14 (Improper decoding of specific SV7 files) closed by r2d
fixed
15:31 Changeset [287] by zorg
*
libmpc/branches/r2d/win32/libcommon.vcproj
* …
Misc msvc project fixes
15:29 Changeset [286] by zorg
*
libmpc/branches/r2d/include/mpc/mpcdec.h
Fix headers once again
04/20/07:
23:17 Changeset [285] by r2d
*
libmpc/branches/r2d/libmpcdec/mpc_demux.c
pow works with msvc, not powf
22:53 Changeset [284] by r2d
*
libmpc/branches/r2d/libmpcdec/mpc_decoder.c
* …
corrected seeking to beginning of the file bug (sv7 only)
21:59 Changeset [283] by r2d
*
winamp-musepack/trunk/mpc_player.cpp
I know, I know …
21:38 Changeset [282] by r2d
*
libmpc/branches/r2d/Makefile.am
* …
added wavcmp utility
21:36 Changeset [281] by r2d
*
libmpc/branches/r2d/libmpcdec/mpc_demux.c
corrected file length error
04/19/07:
23:39 Ticket #2 (Mpcdec) closed by zorg
wontfix: Leave full-featured decoder to external apps and only provide sample …
23:27 Ticket #14 (Improper decoding of specific SV7 files) created by DEATH
Libmpcdec decodes this file properly while lower frequencies (?) are …
23:23 Changeset [280] by zorg
*
libmpc/branches/r2d/include/mpc/mpcdec.h
Fix broken headers
19:56 Changeset [279] by r2d
*
libmpc/branches/r2d/mpcdec/mpcdec.c
can now use mpcdec to check if a file is corrupted
19:55 Changeset [278] by r2d
*
libmpc/branches/r2d/libmpcdec/mpc_demux.c
was always returning error after last frame
04/17/07:
22:12 Changeset [277] by zorg
*
libmpcdec/tags/release-1.2.6
* …
1.2.6 tag
22:05 Changeset [276] by zorg
*
libmpcdec/trunk/ChangeLog
* …
Prepare 1.2.6 release
21:48 Changeset [275] by zorg
*
libmpcdec/trunk/src/mpc_decoder.c
Revert r160 as it breaks some files due to some encoder bug
21:28 Changeset [274] by zorg
*
libmpcdec/trunk/src/Makefile.am
* …
Make sample app use static libraries Fix infinite loop bug on large files
14:10 Changeset [273] by r2d
*
libmpc/branches/r2d/libmpcdec/mpc_demux.c
- added return codes for mpc_demux_decode - refill buffer only if bit …
14:06 Changeset [272] by r2d
*
libmpc/branches/r2d/mpcenc/config.h
* …
- added unicode (UTF-8) autodetection for unix - changed --longhelp about …
04/16/07:
21:55 Changeset [271] by r2d
*
libmpc/branches/r2d/libmpcdec/mpc_demux.c
oups
21:53 Changeset [270] by r2d
*
libmpc/branches/r2d/libmpcdec/mpc_demux.c
initialized all the decoding buffer to 0
20:12 Changeset [269] by r2d
*
libmpc/branches/r2d/libmpcdec/mpc_demux.c
Improved decoding robustness
19:37 Changeset [268] by r2d
*
libmpc/branches/r2d/libmpcdec/mpc_demux.c
Improved decoding robustness
00:04 Changeset [267] by r2d
*
libmpc/branches/r2d/libmpcdec/mpc_demux.c
be sure allocated size is at least used size !
04/15/07:
23:40 Changeset [266] by r2d
*
libmpc/branches/r2d/libmpcdec/internal.h
* …
Improved decoder robustness against corrupted files
23:39 Changeset [265] by r2d
*
libmpc/branches/r2d/libmpcdec/streaminfo.c
sign issue in replay gain reading in sv7
23:37 Changeset [264] by r2d
*
libmpc/branches/r2d/include/mpc/reader.h
* …
added a way to open a reader with an already open file (patch by DEATH)
04/12/07:
22:57 Changeset [263] by zorg
*
libreplaygain/autogen.sh
Useless file, use Makefile.cvs instead
22:53 Changeset [262] by zorg
*
libmpc/branches/r2d/libmpcdec/mpc_decoder.c
* …
Fix cmake for mpcgain Remove builtin math functions
22:42 Changeset [261] by zorg
*
libreplaygain/autogen.sh
* …
Add autogen.sh to make autotools useable Full cmake update
21:44 Changeset [260] by r2d
*
libmpc/branches/r2d/include/Makefile.am
added missing Makefile.am
04/07/07:
10:43 Ticket #4 (Port winamp plugin to libmpcdec) closed by r2d
fixed
10:42 Ticket #8 (make a lib from the replay gain app) closed by r2d
fixed
03/30/07:
19:03 Changeset [259] by r2d
*
libmpc/branches/r2d/libmpcdec/mpc_decoder.c
init scalefactors to 0 because of an encoder bug
13:53 Changeset [258] by r2d
*
winamp-musepack/trunk/mpc_player.cpp
* …
- corrected a bug crashing winamp when trying to see informations on a …
03/29/07:
23:48 Changeset [257] by r2d
*
winamp-musepack/trunk/winamp-musepack.rc
Comment control supports multi line
18:29 Changeset [256] by r2d
*
libmpc/branches/r2d/mpcdec/mpcdec.c
divide by 0 bug removed
17:20 Changeset [255] by r2d
*
winamp-musepack/trunk/mpc_logo.bmp
* …
added logo
15:42 Changeset [254] by r2d
*
winamp-musepack/trunk/mpc_player.cpp
* …
- tag writing OK - better tag reading - maybe less pb with x64
13:16 Changeset [253] by r2d
*
winamp-musepack/trunk/mpc_player.cpp
- tags in accentuated files can now be read - tags are converted from …
03/28/07:
21:19 Changeset [252] by r2d
*
libmpc/branches/r2d/mpcgain/mpcgain.c
mpcgain doesn't crash anymore on read only files
20:56 Changeset [251] by r2d
*
winamp-musepack/trunk/mpc_player.cpp
More details on files (gain info)
19:19 Changeset [250] by r2d
*
winamp-musepack/trunk/mpc_player.cpp
* …
- can now read file tags and display - doesn't work with accentuated file …
17:04 Changeset [249] by r2d
*
winamp-musepack/trunk/mpc_player.cpp
* …
added native windows GUI (work in progress)
16:59 Changeset [248] by r2d
*
winamp-musepack/trunk/in2.h
* …
moved project files
16:56 Changeset [247] by r2d
*
winamp-musepack/trunk/winamp-musepack/mpc_info.cpp
* …
removed .net files
12:39 Changeset [246] by r2d
*
libmpc/branches/r2d/mpc2sv8/mpc2sv8.c
Corrected a mpc2sv8 bug
03/27/07:
12:34 Changeset [245] by r2d
*
libmpc/branches/r2d/libmpcdec/mpc_decoder.c
Corrected a sv7 length decoding bug
11:47 Changeset [244] by r2d
*
libmpc/branches/r2d/mpcenc/config.h
update version because of bug correction
11:23 Changeset [243] by r2d
*
libmpc/branches/r2d/libmpcdec/mpc_decoder.c
* …
corrected pns encoding/decoding bug (doesn't change bitstream for quality …
03/26/07:
13:27 Changeset [242] by r2d
*
libmpc/branches/r2d/libmpcdec/mpc_decoder.c
added include for windows
13:25 Changeset [241] by r2d
*
libmpc/branches/r2d/mpcenc/mpcenc.c
* …
added windows includes
13:23 Changeset [240] by r2d
*
libmpc/branches/r2d/CMakeLists.txt
* …
CMakeLists.txt update to build replaygain using libreplaygain
13:21 Changeset [239] by r2d
*
libreplaygain/CMakeLists.txt
* …
CMakeLists.txt update
03/25/07:
22:23 Changeset [238] by r2d
*
libmpc/branches/r2d/CMakeLists.txt
* …
Changed CMakeLists.txt files for Windows buid (doesn't work for mpcgain …
22:13 Changeset [237] by r2d
*
libmpc/branches/r2d/libmpcdec/mpc_bits_reader.h
corrected the high bitrate bug (decoder only bug)
22:06 Changeset [236] by r2d
*
libmpc/branches/r2d/CMakeLists.txt
* …
- reverted last change (CMakeLists.txt are back)
17:57 Changeset [235] by zorg
*
libmpc/branches/r2d/CMakeLists.txt
* …
Remove unmaintained cmake build files
03/22/07:
20:58 Changeset [234] by r2d
*
libmpc/branches/r2d/mpc2sv8/mpc2sv8.c
- mpc2sv8 doesn't overwrite output file anymore
20:24 Changeset [233] by r2d
*
libmpc/branches/r2d/libmpc.kdevelop
* …
- added build date to mpcenc - mpc2sv8 check for stream version
03/17/07:
01:25 Changeset [232] by r2d
*
libmpc/branches/r2d/Makefile.am
* …
patch from xmixahlx : - moved replaygain outside - removed build system …
01:11 Changeset [231] by r2d
*
libreplaygain/Makefile.am
* …
added files from xmixahlx
01:01 Changeset [230] by r2d
*
libreplaygain/include/replaygain
* …
moved files in the right dirs
00:53 Changeset [229] by r2d
*
libreplaygain/include
moving replaygain in it's own module
00:52 Changeset [228] by r2d
*
libreplaygain
moving replaygain in it's own module
03/16/07:
16:56 Changeset [227] by r2d
*
xmms-musepack/branches/r2d/src/libmpc.cpp
- if pns status is unknown, pns = 0xFF
16:54 Changeset [226] by r2d
*
libmpc/branches/r2d/libmpcdec/mpc_demux.c
* …
- added sv8 options to mpcenc - some change in mpcdec to correctly display …
03/13/07:
00:34 Changeset [225] by r2d
*
libmpc/branches/r2d/Makefile.am
* …
applied the patch from xmixahlx : - libreplaygain is now a shared library …
03/12/07:
20:18 SV8Specification edited by r2d
(diff)
20:14 Changeset [224] by r2d
*
libmpc/branches/r2d/mpcenc/mpcenc.c
- corrected date
19:56 Changeset [223] by r2d
*
libmpc/branches/r2d/mpcenc/mpcenc.c
- corrected encoder version info
03/10/07:
15:06 Changeset [222] by r2d
*
libmpc/branches/r2d/mpcenc/mpcenc.c
* …
- applyed same changes as changeset [99] (what was EnableTags used for ?)
02/17/07:
21:18 Changeset [221] by r2d
*
libmpc/branches/r2d/libmpcenc/bitstream.c
* …
- speed optimizations
18:49 Changeset [220] by r2d
*
libmpc/branches/r2d/include/mpc/streaminfo.h
* …
- updated according to the spec - now reads / write beginning / end …
16:14 Changeset [219] by r2d
*
libmpc/branches/r2d/libmpcdec/Makefile.am
* …
- speed improvements (mainly inlining)
15:58 Changeset [218] by r2d
*
xmms-musepack/branches/r2d/src/libmpc.cpp
* …
- update for replay gain
14:22 SV8Specification edited by zorg
Align stuff (diff)
02/15/07:
12:32 SV8Specification edited by r2d
(diff)
01:41 SV8Specification edited by zorg
Mostly Cosmetics, extract RG from SH (diff)
02/13/07:
22:50 Changeset [217] by zorg
*
libmpc/branches/r2d/mpcdec/CMakeLists.txt
remove winmm stuff..
22:49 Changeset [216] by zorg
*
libmpc/branches/r2d/mpcdec/CMakeLists.txt
mpcdec now needs libm
13:31 Changeset [215] by r2d
*
libmpc/branches/r2d/libmpcdec/Makefile.am
- updated API version
12:25 Changeset [214] by r2d
*
libmpc/branches/r2d/libmpcdec/streaminfo.c
- there is not yet sv > 8
12:13 Changeset [213] by r2d
*
libmpc/branches/r2d/mpcenc/mpcenc.c
- mpcenc should now support encoding from pipe with unknow file length …
11:40 Changeset [212] by r2d
*
libmpc/branches/r2d/include/mpc/mpcdec.h
* …
- changed replay gain implementation (using sv8 representation)
02/11/07:
21:17 Changeset [211] by zorg
*
libmpcdec/tags/release-1.2.5
1.2.5 tag
21:11 Changeset [210] by zorg
*
libmpcdec/trunk/configure.ac
Bump version to 1.2.5
20:58 Changeset [209] by zorg
*
libmpcdec/trunk/ChangeLog
Add 1.2.5 changelog
20:43 Changeset [208] by zorg
*
xmms-musepack/branches/r2d/autogen.sh
* …
Missing executable state on some scripts
20:39 Changeset [207] by zorg
*
libmpc/branches/r2d/CMakeLists.txt
* …
Include mpc2sv8 to cmake build system
02/09/07:
18:57 Changeset [206] by r2d
*
libmpc/branches/r2d/libmpcdec/internal.h
* …
- corrected a bug where very short frames ( < 1 byte, generally silence) …
12:31 Changeset [205] by r2d
*
libmpc/branches/r2d/include/mpc/mpcdec.h
* …
- corrected a small bug - added copy of header and footer data (tags) of …
02/08/07:
21:36 Changeset [204] by r2d
*
libmpc/branches/r2d/include/mpc/mpc_types.h
* …
- file length should be OK for all files - seems there is a bug at end of …
14:29 Changeset [203] by r2d
*
libmpc/branches/r2d/Makefile.am
* …
- added sv7 to sv8 conversion utility (still work to do, but able to …
01/20/07:
21:43 Changeset [202] by r2d
*
xmms-musepack/branches/r2d/src/libmpc.cpp
* …
- added more precision to encoding quality information
21:43 Changeset [201] by r2d
*
libmpc/branches/r2d/include/mpc/streaminfo.h
* …
- added more precision to encoding quality information
20:23 Changeset [200] by r2d
*
libmpc/branches/r2d/mpcenc/mpcenc.c
- removed xlevel stuff
12:13 SV8Specification edited by r2d
(diff)
01/09/07:
22:56 Changeset [199] by zorg
*
libmpcdec/trunk/src/Makefile.am
- Backwards binary compatibility was broken since 1.2.3
22:22 Changeset [198] by zorg
*
libmpcdec/trunk/configure.ac
* …
- Fix missing internal.h in 'make dist' - Simplify types size detection in …
11:48 Changeset [197] by r2d
*
libmpcdec/trunk/src/mpc_decoder.c
changed mpc_decoder_decode_frame so it should be compatible with programs …
01/02/07:
20:37 SV7Specification edited by r2d
(diff)
12/30/06:
17:49 Changeset [196] by r2d
*
libmpc/branches/r2d/libmpcdec/internal.h
* …
- moved skip_id3v2 to demuxer and changed so it doesn't need seek (not …
12/29/06:
15:21 Changeset [195] by r2d
*
libmpc/branches/r2d/include/mpc/mpc_types.h
* …
- moved libmpcdec includes in /mpc - removed mppdec.h and mpp.h - mpcenc …
12/28/06:
12:11 Changeset [194] by r2d
*
libmpc/branches/r2d/libmpcenc/bitstream.c
* …
win32 compilation corrections
12/27/06:
22:52 Changeset [193] by r2d
*
winamp-musepack/trunk/winamp-musepack/mpc_info.cpp
* …
- corrected tag reading bug for utf8 strings - tag writing works but need …
20:53 SV8Specification edited by r2d
(diff)
00:55 SV8Specification edited by r2d
(diff)
12/25/06:
23:45 Changeset [192] by r2d
*
winamp-musepack/trunk/winamp-musepack/in_mpc.cpp
* …
added tag writing, but TagLib::FileRef::save() make all crash and I'm too …
03:15 Changeset [191] by r2d
*
winamp-musepack/trunk/winamp-musepack/in_mpc.cpp
* …
- Added UI - Display tag & stream info (can't edit)
12/24/06:
18:50 Changeset [190] by r2d
*
winamp-musepack/trunk/winamp-musepack/in_mpc.cpp
* …
added licensing terms
17:17 Changeset [189] by r2d
*
winamp-musepack/trunk/winamp-musepack/mpc_player.cpp
* …
Added TagLib support (as a static lib). Used to display track title.
12/23/06:
17:07 Changeset [188] by r2d
*
winamp-musepack/trunk/winamp-musepack/in_mpc.cpp
* …
- removed file info bug - improved thread reactivity
13:52 Changeset [187] by r2d
*
winamp-musepack/trunk/winamp-musepack.suo
removed uneeded file
13:46 Changeset [186] by r2d
*
winamp-musepack
* …
import winamp musepack plugin. supports play, seek, pause, stop and bugs …
13:38 Changeset [185] by r2d
*
libmpc/branches/r2d/common/huffman.c
* …
dev tools only for gcc
12/21/06:
13:45 Changeset [184] by r2d
*
libmpc/branches/r2d/mpcgain/mpcgain.c
moved declarations
13:37 Changeset [183] by r2d
*
libmpc/branches/r2d/mpcgain/mpcgain.c
- added peak calculation - gain results are now written to sv8 files
12/20/06:
23:31 Changeset [182] by r2d
*
libmpc/branches/r2d/libreplaygain/gain_analysis.c
* …
- scaled libmpcdec output so I now have meaningful results - removed gain …
21:53 SV8Specification edited by zorg
(diff)
21:45 Changeset [181] by zorg
*
libmpc/branches/r2d/CMakeLists.txt
* …
Make mpcgain build with cmake
21:21 Changeset [180] by r2d
*
libmpc/branches/r2d/Makefile.am
* …
added libreplaygain and mpcgain
20:42 Changeset [179] by r2d
*
libmpc/branches/r2d/libmpcdec/mpc_bits_reader.c
* …
- bugfix
14:47 Changeset [178] by r2d
*
libmpc/branches/r2d/mpcdec/mpcdec.c
- removed unused decoder
14:41 Changeset [177] by r2d
*
libmpc/branches/r2d/libmpcdec/mpc_decoder.c
- corrected decoded length (tested on sv8, not tested on sv7)
13:25 Changeset [176] by r2d
*
libmpc/branches/r2d/libmpcenc/encode_sv7.c
- corrected info length
01:00 Changeset [175] by zorg
*
libmpc/branches/r2d/win32/mpcdec.sln
* …
Cosmetics
00:57 Changeset [174] by zorg
*
libmpc/branches/r2d/win32/libcommon.vcproj
* …
Update win32 project files
00:54 Changeset [173] by zorg
*
libmpc/branches/r2d/mpcenc/mpcenc.h
Remove default cvd_fastlog
00:53 Changeset [172] by zorg
*
libmpc/branches/r2d/libmpcdec/mpc_bits_reader.c
Remove C99 construct
12/19/06:
23:02 Changeset [171] by zorg
*
libmpc/branches/r2d/CMakeLists.txt
* …
Fix endianess
22:27 Changeset [170] by zorg
*
mppenc/trunk/CMakeLists.txt
* …
Fix endianness issues
22:02 Changeset [169] by zorg
*
libmpc/branches/r2d/Makefile.cvs
symlinks won't work on some systems
22:01 Changeset [168] by zorg
*
libmpc/branches/r2d/configure.in
put config.h in include directory
21:53 Changeset [167] by zorg
*
libmpc/branches/r2d/configure.in
put some autotools stuff into separate dir
21:48 Changeset [166] by zorg
*
libmpc/branches/r2d/CMakeLists.txt
* …
mppenc mutated into mpcenc, part 2
21:39 Changeset [165] by zorg
*
libmpc/branches/r2d/mpcenc/CMakeLists.txt
* …
mppenc mutated into mpcenc, part 1
21:34 Changeset [164] by zorg
*
libmpc/branches/r2d/mpcenc
mppenc mutated into mpcenc, prologue
12:08 Changeset [163] by r2d
*
libmpc/branches/r2d/mpcdec/Makefile.am
* …
- removed warning / error in mpcdec compilation
02:08 Changeset [162] by zorg
*
libmpc/branches/r2d/CMakeLists.txt
* …
Fix mpcdec compilation for latest libmpcdec Fix and update cmake build …
12/18/06:
20:52 Changeset [161] by r2d
*
libmpc/branches/r2d/common/huffman.c
* …
- changed entropy coding (all huffman tables are canonical) - scalefactor …
12/12/06:
00:57 Changeset [160] by r2d
*
libmpcdec/trunk/src/mpc_decoder.c
- improved cutted stream decoding
12/10/06:
19:48 Changeset [159] by r2d
*
libmpc/branches/r2d/libmpcenc/quant.c
- variable name correction
19:42 Changeset [158] by r2d
*
libmpc/branches/r2d/libmpcdec/mpc_decoder.c
- improved cutted stream decoding - sv7 decoding cleanup
12/09/06:
23:00 Changeset [157] by r2d
*
libmpc/branches/r2d/common/Makefile.am
* …
- added huffman codes generation utility
22:45 Changeset [156] by r2d
*
libmpc/branches/r2d/include/mpc/mpcmath.h
* …
- removed slow builtin_ functions
12/07/06:
20:44 Changeset [155] by zorg
*
libmpcdec/tags/release-1.2.4
1.2.4 tag
20:41 Changeset [154] by zorg
*
libmpcdec/trunk/ChangeLog
* …
Prepare for 1.2.4 release
20:35 Changeset [153] by zorg
*
libmpcdec/trunk/src/streaminfo.c
Fix broken stream initialization on non-mpc files
11/25/06:
16:05 Changeset [152] by r2d
*
libmpc/branches/r2d/libmpcdec/mpc_demux.c
- corrected a memory allocation bug
15:19 Changeset [151] by r2d
*
libmpc/branches/r2d/include/mpcdec/mpcdec.h
* …
- updated libmpcdec win32 project files - removed some libmpcdec warnings …
11/24/06:
19:18 Changeset [150] by r2d
*
libmpc/branches/r2d/libmpc.kdevelop
* …
- updated libmpcenc / libmpcdec according to the spec - added seek table …
19:09 SV8Specification edited by r2d
(diff)
11/23/06:
19:17 Changeset [149] by r2d
*
libmpc/branches/r2d/libmpcdec/mpc_demux.c
* …
- merged SI and RG blocks - updated seek table according to the spec in …
18:18 SV8Specification edited by r2d
(diff)
11/21/06:
11:53 SV8Specification edited by r2d
(diff)
11:52 SV8Specification edited by r2d
(diff)
00:31 Changeset [148] by r2d
*
libmpc/branches/r2d/libmpcdec/mpc_demux.c
- corrected a sv8 seeking bug
11/20/06:
20:22 SV8Specification edited by r2d
(diff)
19:53 Changeset [147] by r2d
*
libmpc/branches/r2d/include/mpc/mpc_types.h
* …
- added a first version of the seek table for sv8
11/18/06:
22:38 Ticket #13 (utf8 issue in mppenc) created by r2d
Some of my files (encoded under linux) do not display accents correctly. …
22:20 Ticket #12 (tagging issue in xmms-msepack plugin) created by r2d
when changing tags in xmms plugin, sometimes the new tag values are not …
18:46 Changeset [146] by r2d
*
libmpc/branches/r2d/libmpcdec/internal.h
* …
- added seek table
17:04 Changeset [145] by r2d
*
xmms-musepack/branches/r2d/src/libmpc.cpp
- end of stream bug correction
11/17/06:
21:05 Changeset [144] by r2d
*
xmms-musepack/branches/r2d/configure
* …
- put back seeking
21:04 Changeset [143] by r2d
*
libmpc/branches/r2d/libmpcdec/mpc_decoder.c
* …
- added simple seeking for sv7 and sv8
21:00 Changeset [142] by r2d
*
libmpc/branches/r2d/libmpcenc/bitstream.c
* …
- removed warnings (and bugs)
11/16/06:
13:58 SV8Specification edited by r2d
(diff)
12:35 Changeset [141] by r2d
*
libmpcdec/branches/zorg
removed libmpcdec branche
12:34 Changeset [140] by r2d
*
mppenc/branches/r2d
removed mppenc branche
11/15/06:
18:32 Changeset [139] by r2d
*
libmpc/branches/r2d/libmpcdec/internal.h
* …
- added "SE" block check
13:29 Changeset [138] by r2d
*
libmpc/branches/r2d/Makefile.am
* …
- added CRC check in libmpcdec
01:14 Changeset [137] by r2d
*
libmpc/branches/r2d/Makefile.am
* …
- added build system
00:48 Changeset [136] by r2d
*
libmpc/branches/r2d/include/common/mpc_types.h
- merged types
11/14/06:
18:54 Changeset [135] by r2d
*
libmpc/branches/r2d/common
* …
moved crc32
18:51 Changeset [134] by r2d
*
libmpc/branches/r2d/common/config_types.h
* …
moved common headers
18:45 Changeset [133] by r2d
*
libmpc/branches/r2d/mppenc
still moving libs
18:27 Changeset [132] by r2d
*
libmpc/branches/r2d/libmpcdec
* …
still moving libs
18:26 Changeset [131] by r2d
*
libmpc/branches/r2d/docs
* …
moving libs
17:36 Changeset [130] by r2d
*
libmpc/branches/r2d/libmpcdec
moved libmpcdec
11/13/06:
21:22 Changeset [129] by r2d
*
libmpc/branches/r2d
moved mppenc+libs
21:02 Changeset [128] by r2d
*
libmpc
* …
libs project
20:15 Changeset [127] by r2d
*
xmms-musepack/branches/r2d/Makefile.in
* …
- added "live" bitrate - added pns and gapless info
20:13 Changeset [126] by r2d
*
libmpcdec/branches/zorg/src/decoder.h
* …
- changed decoder struct and length computations
01:36 Changeset [125] by zorg
*
mppenc/tags/mppenc-1.16/src/mppenc.c
Do not fix warnings late at night and create bugs
01:34 Changeset [124] by zorg
*
mppenc/trunk/src/mppenc.c
Do not fix warnings late at night and create bugs
11/12/06:
22:10 Changeset [123] by zorg
*
xmms-musepack/tags/release-1.2.1
made a copy
22:02 Changeset [122] by zorg
*
xmms-musepack/trunk/COPYING
* …
set 1.2.1 xmixahlx patch
21:16 Changeset [121] by zorg
*
mppenc/tags/mppenc-1.16/Changelog
* …
Use proper credits
14:59 Changeset [120] by zorg
*
mppenc/tags/mppenc-1.16
made a copy
14:57 Changeset [119] by zorg
*
libmpcdec/tags/release-1.2.3
made a copy
01:19 Changeset [118] by zorg
*
libmpcdec/trunk/src/mpc_decoder.c
Fix crash due to broken code order execution
11/11/06:
18:22 Changeset [117] by r2d
*
libmpcdec/branches/zorg/include/mpcdec/streaminfo.h
* …
- read "EI" and "RG" blocks - updated "SI" block according to the spec
18:19 Changeset [116] by r2d
*
mppenc/branches/r2d/libmpcenc/encode_sv7.c
* …
- added "EI" and "RG" blocks in output - updated "SI" block according to …
13:24 SV8Specification edited by r2d
(diff)
00:46 Changeset [115] by zorg
*
mppenc/trunk/INSTALL
Removed now outdated note
00:29 Changeset [114] by zorg
*
mppenc/trunk/CMakeLists.txt
Remove special aliasing warnings
00:27 Changeset [113] by zorg
*
libmpcdec/trunk/autogen.sh
chmod +x autogen.sh
11/10/06:
23:54 Changeset [112] by zorg
*
libmpcdec/trunk/ChangeLog
Update changelog
23:18 Changeset [111] by zorg
*
mppenc/trunk/CMakeLists.txt
More conservative default cflags
23:07 Changeset [110] by zorg
*
mppenc/trunk/src/mppenc.c
* …
Cosmetics Remove one annoying warning
22:04 Changeset [109] by zorg
*
mppenc/trunk/CMakeLists.txt
* …
Remove math aliasing issues which were breaking gcc
11/09/06:
21:39 Changeset [108] by r2d
*
libmpcdec/branches/zorg/src/decoder.h
* …
- report file size
14:37 SV8Specification edited by r2d
(diff)
14:32 SV8Specification edited by r2d
(diff)
13:44 Changeset [107] by r2d
*
libmpcdec/branches/zorg/include/mpcdec/mpcdec.h
* …
- gapless playback should now be supported (not verified)
13:42 Changeset [106] by r2d
*
xmms-musepack/branches/r2d/src/libmpc.h
- removed undef TRUE / FALSE
11/08/06:
20:53 Changeset [105] by zorg
*
mppenc/trunk/CMakeLists.txt
* …
Fix cmake compilation on win32 (both for msvc & mingw/cygwin). It's still …
00:20 Changeset [104] by r2d
*
libmpcdec/branches/zorg/include/mpcdec/mpcdec.h
* …
- can read sv7 & sv8 - seek broken (not implemented) - added demuxer in …
00:05 Changeset [103] by r2d
*
xmms-musepack/branches/r2d/src/config.h.in
* …
- changes to follow libmpcdec work in progress - can read sv7 & sv8 - seek …
00:00 Changeset [102] by r2d
*
xmms-musepack/trunk/src/libmpc.cpp
* …
- undone last changes (moved to r2d branche)
11/07/06:
23:30 Changeset [101] by r2d
*
xmms-musepack/branches/r2d
r2d branche creation
11/06/06:
21:39 Changeset [100] by zorg
*
mppenc/trunk/INSTALL
* …
Fix compilation on OpenBSD
11/04/06:
16:45 Changeset [99] by zorg
*
mppenc/trunk/Changelog
* …
Remove tag guessing from filename on unix. Remove now uneeded 'writetags' …
01:06 Changeset [98] by zorg
*
mppenc/trunk/src/mppenc.c
Cosmetics infinite-loop
11/03/06:
23:48 Changeset [97] by zorg
*
mppenc/branches/zorg
* …
Merge 1.16 branch back to trunk
23:35 Changeset [96] by zorg
*
mppenc/branches/zorg/CMakeLists.txt
Ensure cmake >= 2.4. Previous issue unrelated
23:24 Changeset [95] by zorg
*
mppenc/branches/zorg/CMakeLists.txt
Broken option on freebsd
23:18 Changeset [94] by zorg
*
mppenc/branches/zorg/CMakeLists.txt
* …
Add install target and INSTALL file
22:07 Changeset [93] by zorg
*
mppenc/branches/zorg/src/mppdec.h
Horrible typo…
22:00 Changeset [92] by zorg
*
mppenc/branches/zorg/src/mppdec.h
Cosmetics
21:59 Changeset [91] by zorg
*
mppenc/branches/zorg/src/mppenc.c
Cosmetics
21:53 Changeset [90] by zorg
*
mppenc/branches/zorg/src/mppdec.h
Fix compilation on freebsd
21:36 Changeset [89] by zorg
*
mppenc/branches/zorg/CMakeLists.txt
Ensure strict aliasing is disabled as it's currently broken. Use -Os …
20:45 Changeset [88] by zorg
*
mppenc/branches/zorg/src/mppenc.c
Misc cleanup
01:44 Changeset [87] by zorg
*
mppenc/branches/zorg/CMakeLists.txt
* …
various cleanup
00:18 Changeset [86] by zorg
*
mppenc/branches/zorg/src/config.h
* …
Update tags to 1.16
00:10 Changeset [85] by zorg
*
libmpcdec/branches/zorg/include/mpcdec/mpc_types.h
* …
Prefix symbols to prevent conflicts
11/01/06:
23:53 Changeset [84] by zorg
*
mppenc/branches/zorg/src/config.h
* …
Misc cleanup
00:55 Changeset [83] by zorg
*
mppenc/branches/zorg/CMakeLists.txt
* …
Remove verbose cmake Fix compilation on nix
10/31/06:
23:09 Changeset [82] by zorg
*
libmpcdec/trunk/autogen.sh
* …
Clean-up for release
11:50 SV8Specification edited by r2d
(diff)
11:47 Changeset [81] by r2d
*
libmpcdec/branches/zorg/include/mpcdec/mpc_types.h
* …
- first SV8 decoding, it's VERY BADLY implemented. To enable decoding, …
11:41 Changeset [80] by r2d
*
mppenc/branches/r2d/libmpcenc/bitstream.c
- bug correction in block size with CRC
10/30/06:
13:03 SV8Specification edited by r2d
(diff)
10/28/06:
23:38 Changeset [79] by r2d
*
xmms-musepack/trunk/src/libmpc.cpp
* …
- made changes to be able to use libmpcdec (zorg's branch)
10/27/06:
18:42 Changeset [78] by r2d
*
mppenc/branches/r2d/libmpcenc/Makefile.am
* …
- added crc32 - first sv8 encodes, main changes in bitstream.c
13:07 SV8Specification edited by r2d
(diff)
13:03 SV8Specification edited by r2d
(diff)
10/26/06:
22:58 SV8Specification edited by r2d
(diff)
22:57 SV8Specification edited by r2d
(diff)
10/25/06:
15:07 SV8Specification edited by r2d
(diff)
00:51 SV8Specification edited by r2d
(diff)
00:49 SV8Specification edited by zorg
(diff)
00:47 SV8Specification edited by zorg
(diff)
00:27 SV8Specification edited by zorg
(diff)
10/24/06:
21:26 WikiStart edited by zorg
(diff)
21:04 SV8Specification edited by r2d
(diff)
20:30 SV8Specification edited by r2d
(diff)
19:10 SV8Specification edited by r2d
(diff)
10/23/06:
19:39 SV8Specification edited by r2d
(diff)
17:57 SV8Specification created by r2d
17:19 WikiStart edited by r2d
(diff)
10/17/06:
16:55 Changeset [77] by r2d
*
mppenc/branches/r2d/common/minimax.h
* …
- added profile.c in libmpcpsy
13:52 Changeset [76] by r2d
*
mppenc/branches/r2d/libmpcenc/Makefile.am
* …
- removed tools.c
10/12/06:
23:34 Changeset [75] by zorg
*
libmpcdec/branches/zorg/mpcdec/mpcdec.c
* …
Add wav output
19:15 Ticket #11 (find why float results differ in libmpcenc / libmpcpsy from mppenc) closed by r2d
fixed
19:03 Changeset [74] by r2d
*
mppenc/branches/r2d/common/mpcmath.h
* …
- removed FASTMATH stuff
18:08 Changeset [73] by r2d
*
mppenc/branches/r2d/libmpcenc/quant.c
* …
- modified quantization to use standard functions - can now compile with …
11:54 Changeset [72] by r2d
*
mppenc/branches/r2d/config.guess
* …
- output is now exactly the same as 1.15w
10/07/06:
03:02 Ticket #7 (Make mppenc work again with the libs) closed by r2d
fixed
03:02 Ticket #6 (libmpcenc creation) closed by r2d
fixed
03:01 Ticket #5 (libmpcpsy creation) closed by r2d
fixed
02:58 Ticket #11 (find why float results differ in libmpcenc / libmpcpsy from mppenc) created by r2d
the last digits of some floats calculations are not exactly the same as in …
02:56 Ticket #10 (libmpcpsy code cleanup) created by r2d
* clean the libmpcpsy code * move exported functions declarations in a …
02:54 Ticket #9 (libmpcenc code cleanup) created by r2d
* clean the libmpcenc code * move exported functions declarations in a …
02:49 Changeset [71] by r2d
*
mppenc/branches/r2d/Makefile.am
* …
- fixed a LOT of bugs - fixed a bug that took me 2 days to find
- … 10/06/06:
23:57 SV8ScheduleOfConditions edited by shy
grammar (diff)
23:55 ProposedRoadmap edited by shy
clarifications and grammar fixes (diff)
18:51 Changeset [70] by zorg
*
libmpcdec/branches/zorg/include/mpcdec/mpcdec.h
* …
Added primitive mpcdec
17:26 Changeset [69] by zorg
*
libmpcdec/branches/zorg/include/mpcdec/reader.h
* …
Minor indent fix for consistency
17:14 Changeset [68] by zorg
*
libmpcdec/branches/zorg/INSTALL
* …
Separated public interface from private headers Use opaque objects …
10/03/06:
01:57 Changeset [67] by r2d
*
mppenc/branches/r2d/libmpcenc/Makefile.am
* …
- fixed an indianess problem in libmpcenc
10/02/06:
23:20 Changeset [66] by r2d
*
mppenc/branches/r2d/libmpcenc/encode_sv7.c
* …
- mppenc compiles and runs, but output is not playing
20:41 Changeset [65] by r2d
*
mppenc/branches/r2d/common/datatypes.h
* …
- mppenc can be compiled *but* doesn't work (segfault) - some variables …
09/29/06:
18:23 Ticket #8 (make a lib from the replay gain app) created by r2d
Replay gain is not integrated in mppenc (mppenc sets the replay gain …
18:16 Ticket #7 (Make mppenc work again with the libs) created by r2d
16:55 Changeset [64] by r2d
*
mppenc/branches/r2d/Makefile.am
* …
- added libmpcenc and a common directory - can compile libmpcenc and …
01:03 Changeset [63] by zorg
*
libmpcdec/branches/zorg
New branch from trunk
01:02 Changeset [62] by zorg
*
libmpcdec/branches/zorg
Delete outdated branch
00:11 SV8ScheduleOfConditions edited by r2d
(diff)
00:10 ProposedRoadmap edited by r2d
(diff)
09/28/06:
18:30 Changeset [61] by r2d
*
mppenc/branches/r2d/Makefile.am
* …
added kdevelop project files
18:15 Changeset [60] by r2d
*
mppenc/branches/r2d/libmpcpsy/ans.c
* …
added a PsyModel struct, too much members in it. some will be removed …
18:03 Changeset [59] by r2d
*
mppenc/branches/r2d/libmpcpsy
* …
added libmpcpsy directory and moved files
17:49 Changeset [58] by r2d
*
mppenc/branches/r2d
creating mppenc branch from zorg branch to split it into libs
09/27/06:
16:17 Ticket #6 (libmpcenc creation) created by r2d
Create libmpcenc from mppenc sources
16:15 Ticket #5 (libmpcpsy creation) created by r2d
Create libmpcpsy from mppenc sources
12:21 ProposedRoadmap edited by r2d
(diff)
12:17 ProposedRoadmap edited by r2d
(diff)
01:48 SV8ScheduleOfConditions edited by r2d
(diff)
01:25 ProposedRoadmap edited by r2d
(diff)
01:24 Ticket #3 (beep-beep) closed by zorg
fixed: http://trac.musepack.net/trac/changeset/57 Done
01:23 Changeset [57] by zorg
*
mppenc/branches/zorg/src/mppenc.c
Add three beeps after encoding is finished through option --beep
01:21 SV8ScheduleOfConditions edited by r2d
(diff)
01:16 SV8ScheduleOfConditions edited by r2d
(diff)
01:09 SV8ScheduleOfConditions created by r2d
01:04 WikiStart edited by r2d
(diff)
01:01 Changeset [56] by zorg
*
mppenc/branches/zorg/src/mppenc.c
Disable tags by default. Added --writetags option
00:23 ProposedRoadmap edited by zorg
(diff)
00:22 SV7Specification edited by r2d
(diff)
00:21 ProposedRoadmap edited by zorg
(diff)
00:14 SV7Specification edited by zorg
(diff)
00:10 SV7Specification edited by r2d
(diff)
00:08 SV7Specification edited by r2d
(diff)
09/26/06:
23:46 SV7Specification created by r2d
23:38 ProposedRoadmap edited by zorg
(diff)
23:36 WikiStart edited by r2d
(diff)
23:25 ProposedRoadmap created by r2d
21:37 WikiStart edited by r2d
(diff)
20:50 Ticket #4 (Port winamp plugin to libmpcdec) created by zorg
Winamp plugin directly include mpc decoding code. It could be modified to …
01:56 Ticket #3 (beep-beep) created by anonymous
Code to add 3 beeps to signal end of encoding should be added …
01:33 Ticket #2 (Mpcdec) created by zorg
Mppdec is hidden inside musepack-tools, use lots of outdated code, doesn't …
09/25/06:
22:39 Changeset [55] by zorg
*
mppenc/branches/zorg/src/mppenc.c
Cosmetics
22:27 Changeset [54] by zorg
*
mppenc/branches/zorg/src/mppenc.c
Options cleanup. Patch by xmixahlx
21:09 CamelCase edited by trac
(diff)
21:09 TracAccessibility edited by trac
(diff)
21:09 TracAdmin edited by trac
(diff)
21:09 TracBackup edited by trac
(diff)
21:09 TracBrowser edited by trac
(diff)
21:09 TracCgi edited by trac
(diff)
21:09 TracChangeset edited by trac
(diff)
21:09 TracEnvironment edited by trac
(diff)
21:09 TracFastCgi edited by trac
(diff)
21:09 TracImport edited by trac
(diff)
21:09 TracIni edited by trac
(diff)
21:09 TracInstall edited by trac
(diff)
21:09 TracInterfaceCustomization edited by trac
(diff)
21:09 TracLinks edited by trac
(diff)
21:09 TracModPython edited by trac
(diff)
21:09 TracNotification edited by trac
(diff)
21:09 TracPermissions edited by trac
(diff)
21:09 TracPlugins edited by trac
(diff)
21:09 TracQuery edited by trac
(diff)
21:09 TracReports edited by trac
(diff)
21:09 TracRoadmap edited by trac
(diff)
21:09 TracRss edited by trac
(diff)
21:09 TracSearch edited by trac
(diff)
21:09 TracStandalone edited by trac
(diff)
21:09 TracSupport edited by trac
(diff)
21:09 TracSyntaxColoring edited by trac
(diff)
21:09 TracTickets edited by trac
(diff)
21:09 TracTicketsCustomFields edited by trac
(diff)
21:09 TracTimeline edited by trac
(diff)
21:09 TracUnicode edited by trac
(diff)
21:09 TracUpgrade edited by trac
(diff)
21:09 TracWiki edited by trac
(diff)
21:09 WikiDeletePage edited by trac
(diff)
21:09 WikiFormatting edited by trac
(diff)
21:09 WikiHtml edited by trac
(diff)
21:09 WikiMacros edited by trac
(diff)
21:09 WikiNewPage edited by trac
(diff)
21:09 WikiPageNames edited by trac
(diff)
21:09 WikiProcessors edited by trac
(diff)
21:09 WikiRestructuredText edited by trac
(diff)
21:09 WikiRestructuredTextLinks edited by trac
(diff)
21:09 InterMapTxt created by trac
21:09 InterTrac created by trac
21:09 InterWiki created by trac
21:09 TracRevisionLog created by trac
09/23/06:
22:52 Changeset [53] by zorg
*
mppenc/branches/zorg/CMakeLists.txt
* …
Add CMake projects
21:24 Changeset [52] by zorg
*
mppenc/branches/zorg/src/mppenc.c
Fix invalid static use
20:59 Changeset [51] by zorg
*
mppenc/branches/zorg/win32/mppenc.vcproj
Minor changes
20:59 Changeset [50] by zorg
*
mppenc/branches/zorg/src/bitstream.c
* …
Fix header overwrite
18:24 Changeset [49] by zorg
*
mppenc/branches/zorg/src/config.h
* …
Various fixes
14:58 Changeset [48] by zorg
*
mppenc/branches/zorg/win32/mppenc.vcproj
Minor project fixes
14:52 Changeset [47] by zorg
*
mppenc/branches/zorg/bin
* …
Fix project
14:12 Changeset [46] by zorg
*
mppenc/branches/zorg/analy_filter.c
* …
Fix layout…
14:09 Changeset [45] by zorg
*
mppenc/branches/zorg/src/zorg
made a copy
14:06 Changeset [44] by zorg
*
mppenc/branches/zorg/src/predict.h
made a copy
14:05 Changeset [43] by zorg
*
mppenc/branches/zorg/src
Layout
14:05 Changeset [42] by zorg
*
mppenc/branches/zorg/cpu_feat.nas
* …
Remove more stuff
14:03 Changeset [41] by zorg
*
mppenc/branches/zorg/.new.downmix.c
* …
Remove auxiliary stuff
09/22/06:
23:03 Changeset [40] by zorg
*
libmpcdec/trunk/include/mpcdec/decoder.h
* …
Remove minor warnings
22:39 Changeset [39] by zorg
*
mppenc/trunk/encode_sv7.c
Add fast seeking header data in reserved header data Enable safe fast …
22:17 Changeset [38] by zorg
*
xmms-musepack/trunk/src/libmpc.cpp
* …
Add optional fast seeking check-box. Patch by Nicolas BOTTI
22:00 Changeset [37] by zorg
*
libmpcdec/trunk/include/mpcdec/decoder.h
* …
Added optional fast seeking, seek table index & various code cleanup. …
09/19/06:
21:44 Changeset [36] by zorg
*
libmpcdec/trunk/include/mpcdec/config_win32.h
* …
Updated win32 build projects
09/17/06:
22:16 Changeset [35] by zorg
*
mppenc/branches/zorg
made a copy
22:05 Changeset [34] by zorg
*
bmp-musepack
* …
Add stuff back from lost repository
21:57 Changeset [33] by zorg
*
mppenc
* …
Create layout
21:56 Changeset [32] by zorg
*
branches
* …
Move libmpcdec stuff into /libmpcdec/
21:52 Changeset [31] by zorg
*
libmpcdec/trunk
made a copy
21:51 Changeset [30] by zorg
*
libmpcdec/tags
made a copy
21:51 Changeset [29] by zorg
*
libmpcdec/branches
made a copy
21:51 Changeset [28] by zorg
*
libmpcdec
20:42 Changeset [27] by zorg
*
branches/zorg/src/synth_filter.c
Cosmetics
20:12 Changeset [26] by zorg
*
branches/zorg/src/synth_filter.c
Dumb typo
20:10 Changeset [25] by zorg
*
branches/zorg/include/mpcdec/config_types.h.in
* …
Fix segfaults when seeking Fix compilation on posix Forgot to remove some …
19:35 Changeset [24] by zorg
*
branches/zorg/include/mpcdec/decoder.h
* …
Second try at merging rockbox changes. Fixed invalid memory write, may …
16:19 Changeset [23] by zorg
*
branches/zorg/include/mpcdec/decoder.h
* …
Revert broken changes from r21
15:54 Changeset [22] by zorg
*
branches/zorg/src/sample.cpp
Add safeguards
09/16/06:
16:55 Changeset [21] by zorg
*
branches/zorg/include/mpcdec/decoder.h
* …
Merge remaining interesting bits from rockbox svn including seeking code
16:53 Changeset [20] by zorg
*
branches/zorg/win32/libmpcdec.vcproj
* …
Fix release mode
16:39 Changeset [19] by zorg
*
branches/zorg/src/streaminfo.c
Fix imported from rockbox svn
16:33 Changeset [18] by zorg
*
branches/zorg/include/mpcdec/decoder.h
* …
Various type size reductions Removed some type warnings Replaced char, …
15:57 Changeset [17] by zorg
*
branches/zorg/include/mpcdec/huffman.h
Reduce types size
15:53 Changeset [16] by zorg
*
branches/zorg/src/mpc_decoder.c
Cosmetics
15:48 Changeset [15] by zorg
*
branches/zorg/include/mpcdec/config_types.h.in
* …
Add 8bit types Win32 is little-endian only currently
15:46 Changeset [14] by zorg
*
branches/zorg/include/mpcdec/math.h
@ fix inline keyword
13:27 Changeset [13] by zorg
*
branches/zorg/win32/libmpcdec.dsp
* …
Add msvc2005 projects
13:26 Changeset [12] by zorg
*
branches/zorg
made a copy
13:06 Changeset [11] by zorg
*
trunk/src/mpc_decoder.c
@ C99 isn't supported on msvc
08/15/06:
15:41 WikiStart edited by anonymous
(diff)
08/12/06:
16:40 Ticket #1 (test) closed by anonymous
invalid
16:38 WikiStart edited by anonymous
(diff)
16:35 Changeset [10] by zorg
*
trunk/ChangeLog
* …
Update to 1.2.3 trunk
16:31 Changeset [9] by zorg
*
tags/release-1.2.2
made a copy
16:31 Changeset [8] by zorg
*
tags/release-1.2.1
made a copy
16:26 Changeset [7] by zorg
*
trunk/ChangeLog
* …
Update to 1.2.2
16:24 Changeset [6] by zorg
*
trunk/ChangeLog
* …
Update to 1.2.1
16:23 Changeset [5] by zorg
*
tags/release-1.2
made a copy
16:22 Changeset [4] by zorg
*
trunk/include/mpcdec/mpcdec.h
Added missing rename for 1.2
16:21 Changeset [3] by zorg
*
trunk/AUTHORS
* …
Update to 1.2 (work in progress)
16:15 Changeset [2] by zorg
*
tags/release-1.1
made a copy
16:13 Changeset [1] by zorg
*
branches
* …
Initial commit
06/01/06:
17:42 Ticket #1 (test) created by anonymous
QUOTE (shadowking @ Aug 19 2009, 09:54)
128k is a reduction in standards. I am not telling anyone to NOT use it as that would be anti-freedom. This new mantra " just use lossless and stuff the other format cause mp3 is universal 128k should be fine" I find objectionable.
I like lossless , But shouldn't we be using it outside of our Pc as well ? I would like to take the same quality library everywhere i can. If HA members don't demand HQ playback DAP (gapless, lossless, exotic lossy..) - who will ?
I like lossless , But shouldn't we be using it outside of our Pc as well ? I would like to take the same quality library everywhere i can. If HA members don't demand HQ playback DAP (gapless, lossless, exotic lossy..) - who will ?
Completely agree.
QUOTE (2Bdecided @ Aug 20 2009, 14:00)
People who don't care about audio quality could just transcode MPC to mp3. But I don't think such people used MPC in the first place.
For DAP/phone/car I would rather do that then rerip, I consider the remaining quality easily high enough for those purposes. For quality playback at home (without computer that is) I would convert to WAV and have the same quality as the Musepack.
Only for the existing Musepack files of course.
QUOTE (2Bdecided @ Aug 20 2009, 14:00)
They do - they need to re-rip to lossless while they still can. If they wait until the next new DAP/car/phone/whatever they want to buy doesn't have MPC support, they might find they don't have the time / hardware / CDs left to re-rip then! ...
Well the time will probably come that they have to re-encode or re-rip. But whether to do it now or later or (with very low chance) never is a personal thing.
When using mpc only on a pc there will be a lot of time until re-encoding will be necessary.
When using mpc on a mobile DAP AFAIK it can be done only with Rockbox armed players. These players are so old that in case that somebody uses them today he won't have a problem to use them for some more years IMO.
Of course with an ever-growing music library it would be wise to switch rather earlier than later.
But even then this is a question of strategy. A useful argument may be 'Within two years memory of mobile DAPs will be so large that I can use lossless (or very high quality lossy like lossyWAV + lossless). I can wait another two years.'
So it's all up to users' preferences.
2Bdecided has a valid point here. CDs don’t live forever, even pressed ones don’t. Of course hard drives die as well. But you can easily make backups. You can even fully automate that process and have at least two full copies of your library on different physical drives at any given time.
That’s the real advantage of lossless and that’s the reason why I’m currently re-ripping my collection to FLAC. I used Musepack before so I’m probably the more paranoid type anyway. But the point is that for a backup, i.e. for redundant storage of the original data an approximation of that data (and thus any lossy format) is just not good enough.
As for Muspack’s own problems. I agree with what has been said already.
I feel Musepack is a little like the OggMedia container format. That was a great hack to have because it enabled Vorbis audio for movies. Then »real« modern container formats emerged – Matroska and MP4 – and made OGM obsolete.
Musepack isn’t a hack of course. But the situation was somewhat similar. It provided unproblematic transparency when MP3 couldn’t. But then MP3 improved, Vorbis and AAC came along. Musepack lost its advantage and the other formats won with their wider support throughout the industry.
That’s the real advantage of lossless and that’s the reason why I’m currently re-ripping my collection to FLAC. I used Musepack before so I’m probably the more paranoid type anyway.
But the point is that for a backup, i.e. for redundant storage of the original data an approximation of that data (and thus any lossy format) is just not good enough.As for Muspack’s own problems. I agree with what has been said already.
- Missing hardware support is probably the biggest factor.
- With all the excitement around the development, listening tests etc. of the other codecs Musepack just fell by the wayside. Yes, it’s mature, it’s stable, it produces great transparent quality. But there hasn’t been anything new to talk about for a long time to get people’s attention. Even stream version 8 was more of a minor note.
- Musepack users are likely to be the ones who are paranoid about quality. That’s also the user group with the strongest move towards lossless.
I feel Musepack is a little like the OggMedia container format. That was a great hack to have because it enabled Vorbis audio for movies. Then »real« modern container formats emerged – Matroska and MP4 – and made OGM obsolete.
Musepack isn’t a hack of course. But the situation was somewhat similar. It provided unproblematic transparency when MP3 couldn’t. But then MP3 improved, Vorbis and AAC came along. Musepack lost its advantage and the other formats won with their wider support throughout the industry.
QUOTE (2Bdecided @ Aug 19 2009, 14:28)
1.5TB HDD = £86 = about 3 pence per CD lossless.
Ah yes...
mind you a new CD here in Sweden is about £17, so a 1.5TB HDD, with room for very roughly 3500 lossless albums makes the whole idea rather amusing.
hehe, that means you're paying around £59000 to fill it up
(another amusing number is if RIAA would find such a collection, I'd estimate their claim somewhere around £1.000.000.000.000.000.000.000.000.000.000)
QUOTE (David Nordin @ Aug 20 2009, 16:33)
a new CD here in Sweden is about £17
Ouch! Really, still? CD prices have collapsed here in the UK. You can still find (quite) expensive shops, but they're going out of business. And supermarkets started doing legal downloads, pushing prices down further.e.g. all chart CDs here for £7.99 or less:
http://www.cdwow.com/
...and everything else (basic things like bread, milk etc) have been going up stupidly these last two years, so music seams very cheap now.
(Though I'm sure there's still more free/pirated music around than paid for music - far more).
Cheers,
David.
QUOTE (Soap @ Aug 19 2009, 03:39)
I do demand HQ playback on my DAP. I'm just not delusional enough to believe I can hear the difference between FLAC and LAME v3 on my DAP, and would rather have the battery life and size advantages of MP3.
How does lossless like Flac measure up to MP3 or AAC in battery life?
I'd imagine if you've got a spinning disk in your DAP then that will give the large FLAC files a major disadvantage but many are flash memory based now. Obviously this makes it less likely that you can fit your entire collection without lossy transcoding, but what if you can? I believe Flac decode is less processor intensive in theory but does dedicated hardware support make the difference, or does bitrate alone have the biggest impact?
AFAIK: Musepack is based on MP2, and therefore only uses one blocksize. As a pro this means you have no blockswitching issues (like with MP3, Vorbis, AAC), but as a con you have to use higher bitrates to reach transparency.
QUOTE (bawjaws @ Aug 20 2009, 17:59)
How does lossless like Flac measure up to MP3 or AAC in battery life? ...
When I switched from mp3 (for the major part) and wavPack lossy to lossyWAV + FLAC on my HD based iRiver H140 battery life turned better in a very noticable way.
Yeah, me too. I will not sacrifice my mp3 quality for disk space.
I am more of the quality than disk quantity.
I am more of the quality than disk quantity.
QUOTE (kwanbis @ Aug 20 2009, 00:18)
QUOTE (nycjv321 @ Aug 19 2009, 01:08)
Musepack is still as good as mp3 if not better and on par with modern codecs and vorbis and aac so why does no one talk about it? I was murking around the forum wiki and found out musepack was opensource which is a big plus for me... and older abx tests have it on par with aotuv or lame so why no talk? is it becuase of slow development? I think this is unfair if the codec is already so good no more tuning is needed..... any reason why people don't use mpc anymore other then compatibility? (converting from lossless to another format isn't too trivial... lol....)
For starters, LAME is almost as good as MPC, and Vorbis can be said to be even better.
So, if LAME is on par with MPC, but it has 50 times the hw support, why bother with MPC?
And if you want better quality than LAME, why don't go with Vorbis wich still has much better HW support than MPC.
Or even more, go with FLAC.
Other problem i see is that for a long time, it was almost abandoned, and no new dev was being done.
This is how i see it.
dude I don't care about hardware support first of all its not only about "hardware support"...... its also about compatibility, licensing, quality....
1. Foobar2000+lossless backups has fixed all my compatibility needs
2. Vorbis (the codec and its encoders (oggenc) are open source (just found out mpc was and which is why I asked what happened)
3. Vorbis achieves "apparent transparency" for most people at q4 128kbs (I encode to q6-8 though)
development doesn't really matter becuase if the codec is already matured then why bother asking "for more"? Its like people talking about neroaac lacking development somewhere else on this forum.... it works great so why ask for more? you can only go so far...... its a lossy codec. I am the one looking for the hardware that supports my music format of choice not the other way around... goes back to the point about a small group of people in closed door rooms choosing codecs for me NOT FOR ME.... granted this is difficult to do but foobar2000 to the rescue!!!
And it sounds like your actually comparing lame to aoTuV LOL..... WOW
telling me to go to vorbis becuase of hardware support really kills your argument of choosing lame becuase it has more support then all the codecs so why not just use lame? wait thats becuase hardware isn't the only factor in choosing a format of choice....
umm why was the original title of this topic change?
QUOTE (nycjv321 @ Aug 21 2009, 01:41)
I am the one looking for the hardware that supports my music format of choice not the other way around...
That's rather limiting.I mean, I could choose vinyl as my music format of choice, but it's not going to play very well in the car
cheers,
David.
QUOTE (nycjv321 @ Aug 21 2009, 08:41)
dude I don't care about hardware support first of all its not only about "hardware support"...... its also about compatibility, licensing, quality....
The only thing MPC has going for it is quality. The quality improvement over LAME to most people and for most samples is negligible. As for licensing, they're both free to use. That's what matters. As for compatibility and hardware support, there's no contest.
And good luck looking for hardware that supports MPC.
QUOTE (twostar @ Aug 21 2009, 08:16)
QUOTE (nycjv321 @ Aug 21 2009, 08:41)
dude I don't care about hardware support first of all its not only about "hardware support"...... its also about compatibility, licensing, quality....
The only thing MPC has going for it is quality. The quality improvement over LAME to most people and for most samples is negligible. As for licensing, they're both free to use. That's what matters. As for compatibility and hardware support, there's no contest.
And good luck looking for hardware that supports MPC.
lol yea so we should just disregard what the license says right? as long as its free? LOL..... let me say it again I don't use mpc... I use vorbis (aoutv) at q6-8 and usually recencode from either that or my lossless backups to aac or lame for my ipod (which I don't use anymore) or my winmo actually I have a vorbis compliment player on it so I could just use vorbis just fine...
QUOTE (2Bdecided @ Aug 21 2009, 04:25)
QUOTE (nycjv321 @ Aug 21 2009, 01:41)
I am the one looking for the hardware that supports my music format of choice not the other way around...
That's rather limiting.I mean, I could choose vinyl as my music format of choice, but it's not going to play very well in the car
*cough*
http://www.roadkillontheweb.com/images/s_hifi4.jpg
QUOTE (shadowking @ Aug 19 2009, 07:54)
I like lossless , But shouldn't we be using it outside of our Pc as well ? I would like to take the same quality library everywhere i can. If HA members don't demand HQ playback DAP (gapless, lossless, exotic lossy..) - who will ?
who said it's not demanded? it's just DAMN EXPENSIVE! i have 100GB of music, and any player which can store them all is simply not an option for me due to the price. anyway, i'm not sure whether such FLAC/Vorbis-capable player exists at all. so i have to transcode to vorbis to maximize the number of tracks which i can store on my player.
QUOTE (Alexxander @ Aug 19 2009, 12:44)
QUOTE (viktor @ Aug 19 2009, 03:03)
the future (present) of music on pc is lossless. on portable it's transparent and widespread (well supported) lossy (mp3 or occasionally aac, ogg). in long term, the future is lossless on portable too...
I doubt the future is lossless because 1- lossless contain needless information 2- lower than lossless bitrates can give awfully good quality 3- songs sold online are mostly lossy and selling rythm is increasing fast (didn't some months ago digital albums sold surpassed traditional audio CD's selling?).
Besides, in the future desktops PC's will have market penetration as high as it has now? I think they will less and less important among all devices (existents and still to be developed).
1) needless? no, hell no. you can't hear *some* part of it, but it's not needless.
2) yes, but now there's no big cost for storing even better quality. you can eliminate artifacts with a 100% rate and you don't have to bother with transcoding issues if you ever want to process the files. if you want some good demostration, save the same jpeg picture 10 times, and compare the last picture to the first.
3) who cares what they do now? if they do, that doesn't mean they will keep doing so for 100 years. even nowadays i only buy lossless anyway. and the music industry is always badly lagging behind (and fighting against) technology.
and at the same time, you seem to totally ignore that
1) disk space gets cheaper
2) bandwidth gets cheaper
3) computing power gets cheaper (for processing)
oh and about my first post in this thread, people seem to forget that i said it's what most likely *will* happen, not what *should* happen. however, in the long term, i don't see problems with lossless everywhere. and your choice for lossy format on your DAP really won't matter if mainstream distribution ever gets lossless.
QUOTE (twostar @ Aug 21 2009, 06:16)
QUOTE (nycjv321 @ Aug 21 2009, 08:41)
dude I don't care about hardware support first of all its not only about "hardware support"...... its also about compatibility, licensing, quality....
The only thing MPC has going for it is quality. The quality improvement over LAME to most people and for most samples is negligible. As for licensing, they're both free to use. That's what matters. As for compatibility and hardware support, there's no contest.
And good luck looking for hardware that supports MPC.
actually you can find hardware support for MPC, its rare but it exists, and your wrong about quaility being the only advantage, On my buddys old ass iriver h320(with new larger hdd) using MPC gives better batt life then mp3 or flac, MPC is VERY FAST and low power to decode, hardware support can come with a simple firmware flash if people request it.
look at vorbis and flac support on sansa players like the clip and fuze, sansa saw the demand, and added support to the firmware, the same can be done with musepack and other formats.
QUOTE (nycjv321 @ Aug 21 2009, 07:35)
QUOTE (twostar @ Aug 21 2009, 08:16)
QUOTE (nycjv321 @ Aug 21 2009, 08:41)
dude I don't care about hardware support first of all its not only about "hardware support"...... its also about compatibility, licensing, quality....
The only thing MPC has going for it is quality. The quality improvement over LAME to most people and for most samples is negligible. As for licensing, they're both free to use. That's what matters. As for compatibility and hardware support, there's no contest.
And good luck looking for hardware that supports MPC.
lol yea so we should just disregard what the license says right? as long as its free? LOL..... let me say it again I don't use mpc... I use vorbis (aoutv) at q6-8 and usually recencode from either that or my lossless backups to aac or lame for my ipod (which I don't use anymore) or my winmo actually I have a vorbis compliment player on it so I could just use vorbis just fine...
last i checked musepack is 100% free and opensource now, Early on it had some copyrighted code in it, but that was fixed a very long time ago and as such is just as free as vorbis.
I use musepack for a long time, and IF sansa can be convenced to add musepack support I would switch back from vorbis, I love aotuv's work, but musepack would likely give me a batt life BOOST rather then loss over mp3(vorbis cuts batt life a bit compared to mp3)
QUOTE (AshenTech @ Sep 10 2009, 16:28)
actually you can find hardware support for MPC, its rare but it exists, and your wrong about quaility being the only advantage, On my buddys old ass iriver h320(with new larger hdd) using MPC gives better batt life then mp3 or flac, MPC is VERY FAST and low power to decode, hardware support can come with a simple firmware flash if people request it.
it doesn't matter at all if there are 2 players on earth which support it. it only matters if it's widespread. 5% more battery life is really not a selling point either, especially not in the format war. you can produce massively superior formats, they won't give a shit if they get their music in mp3 and their player support mp3 only.
QUOTE (AshenTech @ Sep 10 2009, 16:28)
last i checked musepack is 100% free and opensource now, Early on it had some copyrighted code in it, but that was fixed a very long time ago and as such is just as free as vorbis.
yeah, so you should understand that it wasn't there at the right time, so it doesn't matter if it's free now if they should have been free 5 or 10 years ago. monkey's audio is also free now, but it wasn't when it should, and now noone's interested in it.
QUOTE (AshenTech @ Sep 10 2009, 16:28)
I use musepack for a long time, and IF sansa can be convenced to add musepack support I would switch back from vorbis, I love aotuv's work, but musepack would likely give me a batt life BOOST rather then loss over mp3(vorbis cuts batt life a bit compared to mp3)
yeah, you prefer battery life. but 99% of people won't re-encode their music and potentially buy new hardware for 20 mins longer playtime, that's for sure. it's somehwat easier to plug in for an hour for charging.
QUOTE
the future (present) of music on pc is lossless. on portable it's transparent and widespread (well supported) lossy (mp3 or occasionally aac, ogg). in long term, the future is lossless on portable too.
Hum, I don't think so. That thought might work well for the most audiophiles but the majority probably don't even know what lossless means - and my guess is that they don't really worry about the quality at all, as long as it plays, sounds and recognize the music in their brains.
I could say I enjoy listening to high-quality music, for sure, but do I always look for lossless? Not really. In fact, I consider a 3 or 4 minute-song comprising about 30MB each rather an exaggeration, given the fact that you could get even more of that time with video information, which is much richer than just audio stream. All this regardless of how cheap hdd's may and might be today and in the future.
QUOTE (prankstare @ Oct 13 2009, 20:01)
QUOTE
the future (present) of music on pc is lossless. on portable it's transparent and widespread (well supported) lossy (mp3 or occasionally aac, ogg). in long term, the future is lossless on portable too.
Hum, I don't think so. That thought might work well for the most audiophiles but the majority probably don't even know what lossless means - and my guess is that they don't really worry about the quality at all, as long as it plays, sounds and recognize the music in their brains.
I could say I enjoy listening to high-quality music, for sure, but do I always look for lossless? Not really. In fact, I consider a 3 or 4 minute-song comprising about 30MB each rather an exaggeration, given the fact that you could get even more of that time with video information, which is much richer than just audio stream. All this regardless of how cheap hdd's may and might be today and in the future.
releasing lossy is an additional step, since producers always have lossless copy too. decrease of costs of disk space and bandwidth helps eliminating this unnecessary and (in terms of quality) harmful step.
the spread of lossless has already begun, and it can get only wider.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.