HydrogenAudio

Lossy Audio Compression => MPC => Topic started by: nycjv321 on 2009-08-19 01:08:18

Title: Why does there seem to be a lack of interest in Musepack?
Post by: nycjv321 on 2009-08-19 01:08:18
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....)
Title: Why does there seem to be a lack of interest in Musepack?
Post by: Soap on 2009-08-19 01:16:11
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.
Title: Why does there seem to be a lack of interest in Musepack?
Post by: nycjv321 on 2009-08-19 01:27:55
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
Title: Why does there seem to be a lack of interest in Musepack?
Post by: /mnt on 2009-08-19 01:29:00
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.
Title: Why does there seem to be a lack of interest in Musepack?
Post by: rpp3po on 2009-08-19 01:44:02
The point is hardware support.
Title: Why does there seem to be a lack of interest in Musepack?
Post by: /mnt on 2009-08-19 01:51:45
If open source is big plus to you, i would recommend Ogg Vorbis; which offers better compatabilty then Musepack.
Title: Why does there seem to be a lack of interest in Musepack?
Post by: viktor on 2009-08-19 02:03:24
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.
Title: Why does there seem to be a lack of interest in Musepack?
Post by: Antonski on 2009-08-19 02:17:59
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 .
Title: Why does there seem to be a lack of interest in Musepack?
Post by: twostar on 2009-08-19 02:38:46
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?
Title: Why does there seem to be a lack of interest in Musepack?
Post by: shadowking on 2009-08-19 03:31:32
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.

Title: Why does there seem to be a lack of interest in Musepack?
Post by: patmcg on 2009-08-19 07:20:12
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.

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?

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?

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.

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.
Title: Why does there seem to be a lack of interest in Musepack?
Post by: shadowking on 2009-08-19 07:54:23
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 ?
Title: Why does there seem to be a lack of interest in Musepack?
Post by: nycjv321 on 2009-08-19 12:09:55
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.
Title: Why does there seem to be a lack of interest in Musepack?
Post by: Soap on 2009-08-19 12:39:38
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.
Title: Why does there seem to be a lack of interest in Musepack?
Post by: Alexxander on 2009-08-19 12:44:46
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).

...
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.
Title: Why does there seem to be a lack of interest in Musepack?
Post by: Alexxander on 2009-08-19 12:50:57
...
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.
Title: Why does there seem to be a lack of interest in Musepack?
Post by: Grinderman on 2009-08-19 13:11:49
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.
Title: Why does there seem to be a lack of interest in Musepack?
Post by: 2Bdecided on 2009-08-19 13:28:17
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.
Title: Why does there seem to be a lack of interest in Musepack?
Post by: GeSomeone on 2009-08-19 14:49:54
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.
Title: Why does there seem to be a lack of interest in Musepack?
Post by: kornchild2002 on 2009-08-19 16:55:15
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.
Title: Why does there seem to be a lack of interest in Musepack?
Post by: Kitsuned on 2009-08-19 20:24:22
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.
Title: Why does there seem to be a lack of interest in Musepack?
Post by: Destroid on 2009-08-20 00:25:18
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):
Code: [Select]
LAME MP3 =  171x
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
Title: Why does there seem to be a lack of interest in Musepack?
Post by: kwanbis on 2009-08-20 05:18:01
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.
Title: Why does there seem to be a lack of interest in Musepack?
Post by: 2Bdecided on 2009-08-20 09:12:10
I think Musepack is a perfectly usable format for many reasons:

...

- 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.
Title: Why does there seem to be a lack of interest in Musepack?
Post by: halb27 on 2009-08-20 12:06:52
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).
Title: Why does there seem to be a lack of interest in Musepack?
Post by: 2Bdecided on 2009-08-20 13:00:30
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.
Title: Why does there seem to be a lack of interest in Musepack?
Post by: Antonski on 2009-08-20 15:52:07
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.

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.

What is there to talk about anyway? Listening tests? With little to no development, what's the use?
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.
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
Title: Why does there seem to be a lack of interest in Musepack?
Post by: GeSomeone on 2009-08-20 15:56:33
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.
Title: Why does there seem to be a lack of interest in Musepack?
Post by: halb27 on 2009-08-20 16:11:47
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.
Title: Why does there seem to be a lack of interest in Musepack?
Post by: Brother John on 2009-08-20 16:15:15
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.
  • 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.
Title: Why does there seem to be a lack of interest in Musepack?
Post by: David Nordin on 2009-08-20 16:33:19
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)
Title: Why does there seem to be a lack of interest in Musepack?
Post by: 2Bdecided on 2009-08-20 16:46:56
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/ (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.
Title: Why does there seem to be a lack of interest in Musepack?
Post by: bawjaws on 2009-08-20 16:59:51
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?
Title: Why does there seem to be a lack of interest in Musepack?
Post by: vpa on 2009-08-20 17:50:51
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.
Title: Why does there seem to be a lack of interest in Musepack?
Post by: halb27 on 2009-08-20 17:59:42
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.
Title: Why does there seem to be a lack of interest in Musepack?
Post by: Aquamarine on 2009-08-20 18:33:55
Yeah, me too. I will not sacrifice my mp3 quality for disk space.

I am more of the quality than disk quantity.
Title: Why does there seem to be a lack of interest in Musepack?
Post by: nycjv321 on 2009-08-21 01:41:29
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....
Title: Why does there seem to be a lack of interest in Musepack?
Post by: nycjv321 on 2009-08-21 02:44:48
umm why was the original title of this topic change?
Title: Why does there seem to be a lack of interest in Musepack?
Post by: 2Bdecided on 2009-08-21 09:25:40
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.

Title: Why does there seem to be a lack of interest in Musepack?
Post by: twostar on 2009-08-21 13:16:43
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.
Title: Why does there seem to be a lack of interest in Musepack?
Post by: nycjv321 on 2009-08-21 14:35:11
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...
Title: Why does there seem to be a lack of interest in Musepack?
Post by: Soap on 2009-08-21 14:45:15
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 (http://www.roadkillontheweb.com/images/s_hifi4.jpg)


Title: Why does there seem to be a lack of interest in Musepack?
Post by: viktor on 2009-08-21 15:01:56
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.
Title: Why does there seem to be a lack of interest in Musepack?
Post by: viktor on 2009-08-21 15:21:59
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.
Title: Why does there seem to be a lack of interest in Musepack?
Post by: AshenTech on 2009-09-10 16:28:07
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.

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)
Title: Why does there seem to be a lack of interest in Musepack?
Post by: viktor on 2009-09-10 18:44: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.

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.

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.
Title: Why does there seem to be a lack of interest in Musepack?
Post by: prankstare on 2009-10-13 19:01:23
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.
Title: Why does there seem to be a lack of interest in Musepack?
Post by: viktor on 2009-10-13 19:38:49
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.
Title: Why does there seem to be a lack of interest in Musepack?
Post by: String Theory on 2010-05-19 12:24:50
Musepack didn't interest me until yesterday. After hearing a MPC-song I instantly fell in love with the format. The quality of a q5-file is absolutely great! My Rockboxed Sansa Clip+ is now playing MPC-files all day long :-) ...

Ain't there something we can do to give Musepack the world wide attention it deserves?
Title: Why does there seem to be a lack of interest in Musepack?
Post by: dv1989 on 2010-05-19 13:05:29
After hearing a MPC-song I instantly fell in love with the format. The quality of a q5-file is absolutely great!

Sounds like the placebo effect to me.
Title: Why does there seem to be a lack of interest in Musepack?
Post by: String Theory on 2010-05-19 13:08:06
After hearing a MPC-song I instantly fell in love with the format. The quality of a q5-file is absolutely great!

Sounds like the placebo effect to me.


I mean the complete package... the audio quality is awesome and it encodes so bloody fast. MP3 / AAC / WMA / OGG can't beat that.
Title: Why does there seem to be a lack of interest in Musepack?
Post by: dv1989 on 2010-05-19 13:16:02
By "awesome", I presume you mean transparent. Anyway, most people aren't bothered about the traits of different codecs, and will just use whichever formats the main companies support/push.
Title: Why does there seem to be a lack of interest in Musepack?
Post by: DonP on 2010-05-19 14:07:22
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.


FWIW the trend seems to be keeping compatibility with older formats while the primary purpose of the drive marches on: CD, DVD, Blue-ray,  (next?)

At some point spinning plastic disks of any format may go away.

Back to MPC, I use it on a rockboxed Sansa, but compatibility  is still an issue as all the programs and portables I use can play vorbis.
Title: Why does there seem to be a lack of interest in Musepack?
Post by: Wyld Stallyn on 2013-03-29 15:20:00
but rapidly diminishing disc prices make it increasingly silly not to use lossless.

What is at all silly about striving for efficiency? If I want to cut on wasted disk space and file size -which are both very reasonable choices-, it is not at all silly if I then go out and convert my big fat music files to ones that are only half as big with no level of signal deterioration that is in the slightest practice-relevant. In fact I should argue that it is very silly indeed to be unwilling to use so called lossy formats when those do not actually present a loss in audio quality.

And if you are among the economical bottom it is generally preferable to save those 50€ for that extra HDD, even when you live in a country where hitting bottom doesn't mean living on foodstamps in a cockroach-infested poorly isolated apartment with mould croaching up everywhere. THey could just go into that book that helps you acquire the last inch of professional skill that puts you atop that one main competitor, potentially elevating you into a real, cozy middle-class life. Or maybe you're saving up for a stock investment at the right time. As we say very poetically here in Germany: "Small livestock makes droppings too."

Eh, it just doesn't sound good in English.
Title: Why does there seem to be a lack of interest in Musepack?
Post by: 2Bdecided on 2013-03-29 15:34:31
I bet when you dragged this thread up from the depths you didn't expect such a quick response...
but rapidly diminishing disc prices make it increasingly silly not to use lossless.

What is at all silly about striving for efficiency?
Your "efficiency" calculation has totally ignored efficient use of your time in terms of not having to choose a lossy encoder (you're posting in a Musepack thread - choice of lossy encoder is clearly very important, agonising, and potentially problematic), not having to wait for that lossy encoder to encode, being able to check+fix bad rips years later using cuetools without finding a better copy of the CD, not having to re-rip the whole lot again in the future when you realise you need a different lossy codec, and in the event of re-ripping: not having to re-buy some CDs which have been lost/damaged in the meantime. The potential "inefficiencies" with lossy are many and varied - they have driven most HA users of lossy over to lossless in the end!

Saving a few pence on a HDD in comparison to all this is not efficiency...!

The major disadvantage with lossless is that most people who use lossless also use lossy, and having two copies can be a pain. Having just mp3, if you are happy with it, is much less painful - but it's like having a cassette copy - many people will need to go back to the CD (lossless file) in the end.

Cheers,
David.
Title: Why does there seem to be a lack of interest in Musepack?
Post by: Wyld Stallyn on 2013-03-29 15:37:39
I didn't actually look at the timestamp. Now that I see it, lol.
Your "efficiency" calculation has totally ignored efficient use of your time in terms of not having to choose a lossy encoder (you're posting in a Musepack thread - choice of lossy encoder is clearly very important, agonising, and potentially problematic), not having to wait for that lossy encoder to encode, being able to check+fix bad rips years later using cuetools without finding a better copy of the CD, not having to re-rip the whole lot again in the future when you realise you need a different lossy codec, and in the event of re-ripping: not having to re-buy some CDs which have been lost/damaged in the meantime. The potential "inefficiencies" with lossy are many and varied - they have driven most HA users of lossy over to lossless in the end!

Good points. I have nothing to return.