IPB

Welcome Guest ( Log In | Register )

24 Pages V  « < 22 23 24  
Reply to this topicStart new topic
MP3 repacker
rbrito
post Apr 8 2013, 03:58
Post #576





Group: Members
Posts: 55
Joined: 16-August 05
Member No.: 23948



QUOTE (Omion @ Sep 9 2012, 17:00) *
I've tried to make it compilable on non-Windows platforms, but I don't actually test them. If it compiles with only those 3 changes, I'm impressed! However, note that the SSE optimization is not used outside of Windows.


Would you like some patches and results? I am trying to package it for myself (as a first step).

Later, I may package it for Debian, which would cover a lot of platforms, with different endianness, different sizes for ints etc. But let's start small first. smile.gif

Here is what I have so far: https://github.com/rbrito/mp3packer

QUOTE
It sounds like you made the right changes:
1) I renamed mfu_find_best_config to mfu_find_best_config_base a while back, so yes, that should change.


Great.

QUOTE
2) That function was used in an old version of the multithreaded code, but it was too slow so I used a different algorithm. I guess I left the old OS hooks in, though.


So, the whole code can be ripped apart? Smaller is better, as always. smile.gif I had just created a mini-stub for gettid (which is Linux specific) as:

CODE
+int gettid() {
+       return syscall(SYS_gettid);
+}


Do you happen to have a github account? I can send you github pull requests with some janitorial stuff like this and, of course, I have fixed some variable definitions which were causing GCC to complain about unused variables (they were only used inside ifdefs for windows).

QUOTE
3) Since I don't compile the non-Windows ones I sometimes miss a few includes, and it clearly looks like that should have been included.


I'm willing to send you patches.

QUOTE
What sort of differences are there between the outputs? If everything works perfectly there should be no differences in the uncompressed output. However, one thing I learned very quickly in this project is that encoders sometimes do some quirky things that are handled differently by different decoders, so if they don't match up it could be one of many possibilities (most of which are benign).


I am not the original poster, but the build problems (not quality problems) that I am having are with versions 2.x of mp3packer. With versions 1.2x, I was (actually, am) having a wonderful time, especially when I use it with GNU parallel, which executes one process of mp3packer for each core/thread of my processors.

BTW, mp3packer (as is handbrake/x264) is a fine tool to see if you have heat problems with your CPU/system, while doing something useful. smile.gif
Go to the top of the page
+Quote Post
dj lists
post Aug 14 2013, 10:06
Post #577





Group: Members
Posts: 4
Joined: 27-May 11
Member No.: 91026



Latest version 2.04 is much faster than 2.03 at running --ib but occasionally locks up. Trying this on a group of mp3s will cause it to lock up on different files. 2.03 does not lock up on the same set of mp3s. Happens with 32bit and 64bit versions.

** correction, 2.03 locks up as well. Also, doing it repeatedly on any random mp3 will eventually cause it to lock up.

Even more interesting, I got the 64bit version of 2.03 to lock up when displaying the help info (by giving no input file). It showed everything down to --help and then froze.

This post has been edited by dj lists: Aug 14 2013, 10:16
Go to the top of the page
+Quote Post
ScottE
post Dec 15 2013, 21:33
Post #578





Group: Members
Posts: 1
Joined: 15-December 13
Member No.: 113310



QUOTE (bugbear @ Oct 22 2012, 23:21) *
Here are my diffs:

diff -r mp3packer-2.04/mp3framehuffman-c.c pack_orig/mp3packer-2.04/mp3framehuffman-c.c
337c337
< #if HAS_BYTESWAP
---
> #if 1


Instead of that, a better approach is probably to use the gcc builtin.
Change

CODE
raw = _byteswap_ulong(*int_ptr) << s->bit_index;


to

CODE
raw = __builtin_bswap32(*int_ptr) << s->bit_index;


when using GCC.

The byteswap included in the !HAVE_BYTESWAP case doesn't really work on all architectures, so it's sadly probably more portable to use a GCC builtin than to have more #ifdefs. :-)
Go to the top of the page
+Quote Post
goa pride
post Dec 16 2013, 15:36
Post #579





Group: Members
Posts: 61
Joined: 13-January 12
Member No.: 96416



if you prefer use latest gui and latest encoder and latest 64bit encoder!
http://www.hydrogenaudio.org/forums/index....howtopic=103147
Go to the top of the page
+Quote Post
Porcus
post Jan 25 2014, 10:58
Post #580





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



I nearly got down to 50 percent of original size on a track from this free download: http://grimtownmusic.com/2012/06/06/satanic-panic/

The .zip file is 107 581 440 bytes including a pdf and a picture, unzips to 141 000 002 bytes (!), of which 135 015 653 bytes music, the music mp3pack'd (with -z) down to 101 115 525 bytes.

Now I am getting curious: seven out of twelve tracks are, according to fb2k, lame 3.98r V2 at 320 (EncSpot says 319). Didn't even know that was possible. They compress down to 202 - the "worst", track 4, down to 162. (161 according to EncSpot - couldn't it for the sake of the wow factor had gone down to 159?)

The reason why I do play with mp3packer from time to time, is to see how much is wasted by senseless encoding at usually 320 CBR. But this ... what have they done?


--------------------
One day in the Year of the Fox came a time remembered well
Go to the top of the page
+Quote Post
[JAZ]
post Jan 25 2014, 11:19
Post #581





Group: Members
Posts: 1779
Joined: 24-June 02
From: Catalunya(Spain)
Member No.: 2383



I am guessing that they used the -B ( minimum bitrate) switch. I.e. Encoding to "CBR" using the VBR engine. Probably encspot shows 319 because there is silent parts encoded at 32kbps.
Go to the top of the page
+Quote Post
robert
post Jan 25 2014, 11:51
Post #582


LAME developer


Group: Developer
Posts: 788
Joined: 22-September 01
Member No.: 5



Actually, the lowercase b sets the minimum and uppercase B the maximum framesize. So, yes, it's possible to use the VBR engine to make constant bitrate encodings.
Go to the top of the page
+Quote Post
[JAZ]
post Jan 25 2014, 15:53
Post #583





Group: Members
Posts: 1779
Joined: 24-June 02
From: Catalunya(Spain)
Member No.: 2383



Duh! How bad for someone responsible of the LAME documentation (i.e. me) to make that mistake... sweat.gif Thanks for correcting me.
Go to the top of the page
+Quote Post
Porcus
post Jan 25 2014, 17:15
Post #584





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



Ah. So if I specify -b 320, then Lame will (at least would for 3.98) not attempt to make any use of the top ~100? Audio is usually not too well .zip-able.

Edit: I was wrong about 320 "CBR" yes - it was "VBR". V2, it seems.

This post has been edited by Porcus: Jan 25 2014, 17:16


--------------------
One day in the Year of the Fox came a time remembered well
Go to the top of the page
+Quote Post
[JAZ]
post Jan 25 2014, 19:19
Post #585





Group: Members
Posts: 1779
Joined: 24-June 02
From: Catalunya(Spain)
Member No.: 2383



Let's see if this example is clearer:

A) -V0 ~ 245kbps
B) -V9 ~ 65kbps

C) -V0 -b 64 -B 64 = 64kbps
D) -V9 -b 256 -B 256 = 256kbps

C is probably going to sound worse than B (the encoder will try to keep a level of detail unachievable with the provided bitrate), but their size will be about the same.

D is going to sound like B* (the codec is given more bits than those that it requires, but won't make use of them other than for block padding, and padding tends to be lots of zeroes, easily zip-able), but the size will be like A.


* In --vbr-old, D could sound better than B. This reasoning comes from the fact the older method was determining which bitrate was appropiate for the expected quality for the concrete block that it analized and then encoded it. That's why originally, the --alt-presets had -b 128, and even in the LAME history we can see some of the earlier versions having -b 64 as the default, to prevent the engine from guessing too low of a value.
--vbr-new does not work like that.

This post has been edited by [JAZ]: Jan 25 2014, 19:33
Go to the top of the page
+Quote Post
Porcus
post Jan 27 2014, 09:49
Post #586





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



QUOTE ([JAZ] @ Jan 25 2014, 19:19) *
D is going to sound like B*


Thanks.

Obviously, allowing the user to do what the user asks, is far from fool-proof :-)


--------------------
One day in the Year of the Fox came a time remembered well
Go to the top of the page
+Quote Post
Porcus
post Feb 9 2014, 15:05
Post #587





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



Here is maybe a feature suggestion: Someone needs to extract a channel and "remux" it into a mono mp3 losslessly.

Two threads with different uses:
http://www.hydrogenaudio.org/forums/index....mp;#entry857571
http://www.hydrogenaudio.org/forums/index....showtopic=99206


--------------------
One day in the Year of the Fox came a time remembered well
Go to the top of the page
+Quote Post
no404error
post Feb 9 2014, 17:02
Post #588





Group: Members
Posts: 55
Joined: 23-May 08
From: Rzeczpospolita
Member No.: 53744



QUOTE (Porcus @ Feb 9 2014, 17:05) *
Here is maybe a feature suggestion: Someone needs to extract a channel and "remux" it into a mono mp3 losslessly.

Two threads with different uses:
http://www.hydrogenaudio.org/forums/index....mp;#entry857571
http://www.hydrogenaudio.org/forums/index....showtopic=99206

Good idea smile.gif
Go to the top of the page
+Quote Post
hidn
post Jun 4 2014, 12:30
Post #589





Group: Members
Posts: 55
Joined: 17-April 08
Member No.: 52847



"Must Have" tool for sets. Big Thank You for Great Work.
Go to the top of the page
+Quote Post
Jaff2002
post Jul 17 2014, 03:10
Post #590





Group: Members
Posts: 1
Joined: 17-July 14
Member No.: 116722



Personally I use a custom hacked version in wich I replaced version and padding with zero bytes in exe file. Compressing any MP3 files as archive gives best results. A good suggestion is remove padding in repacking the MP3 file.

This post has been edited by Jaff2002: Jul 17 2014, 03:11
Go to the top of the page
+Quote Post

24 Pages V  « < 22 23 24
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 2nd September 2014 - 03:31