Log in

View Full Version : LameXP v4.21 Final · Build #2382 (2023-12-29)


Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 [24] 25 26 27 28 29 30 31 32 33 34 35 36 37

schiff1108
16th January 2015, 14:03
I would like to understand the approach on tags. What tags should get copied from source to output?
In particular I am missing the tags "composer" and "album artist".
When I check the source file with MediaInfo, I do find the tag values as expected. I have made some shots with using Custom Encoding Parameters, but w/o success.

Thanks.

LoRd_MuldeR
16th January 2015, 22:19
I would like to understand the approach on tags. What tags should get copied from source to output?
In particular I am missing the tags "composer" and "album artist".
When I check the source file with MediaInfo, I do find the tag values as expected. I have made some shots with using Custom Encoding Parameters, but w/o success.

Meta data is extracted from the original file via MediaInfo. It then will be kept in an internal data structure. And finally it will be re-embedded into the output file, according to the individual encoder's capabilities.

One important thing to understand is that there is not the one standard for meta information! Every file format uses its own eccentric way to keep meta information. Some file formats, like e.g. MP3's "ID3v1" tags, are very limited, with only a few pre-defined fields. With those you can only use the pre-defined fields and that's it. At the same time, some other formats are very flexible, because they store arbitrary key-value pairs. On the one hand, this flexibility is great. But on the other hand, it makes it hard to figure out which keys are actually used practice - and which ones are actually recognized by (most) applications. Therefore "copying" meta information from one file format to another one is not as trivial as you might imagine!

The approach that I took with LameXP is that I designed the internal "meta information" data structure roughly as a "smallest common denominator" for what most file formats offer. This data structure will be filled with the meta tags that MediaInfo brings up. However, not every information that MediaInfo might be able to extract from a specific file format necessarily has an equivalent field in the internal data structure! There are far too many different (obscure) tags that might appear in some file to reserve a field for every single one of them. Instead, our internal data structure is restricted to the most important tags. So it's quite possible that we can not retain every single bit of information that MediaInfo has tracked down!


[EDIT]

Currently, the meta information that can be kept in the internal data structure are as follows:
QString m_titel;
QString m_artist;
QString m_album;
QString m_genre;
QString m_comment;
QString m_containerType;
QString m_containerProfile;
QString m_audioType;
QString m_audioProfile;
QString m_audioVersion;
QString m_audioEncodeLib;
unsigned int m_audioSamplerate;
unsigned int m_audioChannels;
unsigned int m_audioBitdepth;
unsigned int m_audioBitrate;
unsigned int m_audioBitrateMode;
unsigned int m_duration;
unsigned int m_year;
unsigned int m_position;
ArtworkModel m_cover;

foxyshadis
16th January 2015, 23:45
Would you consider adding a QMap of unknown and custom tags, that can be re-embedded if the output supports them?

LoRd_MuldeR
16th January 2015, 23:58
Would you consider adding a QMap of unknown and custom tags, that can be re-embedded if the output supports them?

I don't think that would solve anything. Of course, with a Map we can maintain arbitrary key-value pairs. That is very flexible, obviously. So we could simply dump everything that MediaInfo brings up into the Map. That's straight forward. But the real challenge here is that, eventually, we need to re-embed all that information into the output file! For example, the LAME encoder accepts a "--tt" switch to specify the "title" of the track and a "--ta" switch to specify the "artist". Thus, I know that if we are using LAME, then I need to pass the value of m_titel via "--tt" switch and the value of m_artist via "--ta" switch. But what to do with the "PhaseOfMoonWhenThisAlbumWasRecorded" entry, if such key appears in the Map? :confused:

foxyshadis
17th January 2015, 10:28
I don't think that would solve anything. Of course, with a Map we can maintain arbitrary key-value pairs. That is very flexible, obviously. So we could simply dump everything that MediaInfo brings up into the Map. That's straight forward. But the real challenge here is that, eventually, we need to re-embed all that information into the output file! For example, the LAME encoder accepts a "--tt" switch to specify the "title" of the track and a "--ta" switch to specify the "artist". Thus, I know that if we are using LAME, then I need to pass the value of m_titel via "--tt" switch and the value of m_artist via "--ta" switch. But what to do with the "PhaseOfMoonWhenThisAlbumWasRecorded" entry, if such key appears in the Map? :confused:

Well, if you have Ogg/FLAC or APE tags you just write them back as-is, same if you're going from one id3v2 format to another, just copy everything. (Except encoder and created date tags.) For everything else, map if tags are standardized, drop if not; no one's going to seriously expect to see a PhaseOfMoon tag to end up in mp3. You must already have a map of common entries from one format to another, in the form of the conversions to and from your variables, since id3v2 and Ogg tags are completely different, so it's mostly a matter of extending that with more common tags and allowing arbitrary ones to pass through if possible.

(Album Artist is especially extremely common and part of the default file properties GUI in almost every media player, so that in particular should get special treatment. Even if the Vorbis and id3v2 specs don't mention it, the defacto standard is ALBUMARTIST for the comment tag and TPE2 for id3v2.)

I can try to whip something up if you like, I'm free tomorrow.

LoRd_MuldeR
17th January 2015, 15:14
It's not as simple as that, I think. Any solution that is like "if we are going from file format A to file format B then let's do it like this, and if we are going from file format C to file format D then let's do it like that" is not really feasible in practice, because there are way to many possible combinations. Having to implement a special path for each possible combination is no good solution and is hardly extensible. Instead, what we need in practice are solutions that work from any file format to any file format. This, however, requires boiling things down to a "smallest common denominator". And then, of course, not every eccentricity of every file format can be retained. But that's an acceptable trade-off.

For example, the LAME encoder has a dedicated "--ta" switch to set the "artits" of the track. So if the original file had an "artist" tag, we certainly want to pass this via "--ta name" switch, and not via the generic "--tv key=value" switch (introduced with ID3v2.3). Now you could say that we have a few recognized tags that will be passed via dedicated switches and everything else is passed via the generic "--tv" switch. However, what if the original did not have an "artist" tag, but did have a "performer" tag instead? In this case we probably want to pass the value of the "performer" tag to the "--ta" switch, rather than the generic "--tv" switch! Thus, some "smart" mapping of the commonly used tags needs to be implemented.

But we don't want to re-implement this required mapping again and again in every single encoder class! Currently, the required mapping happens at one single point! And that's the FileAnalyzer class. After that, our internal data structure either has a value in its m_artist field, or not. That's a clean design. And the LameEncoder class does not need to care about file format eccentricities, e.g. whether the info originally had been called "artist", "performer" or whatever. LAME simply passes the value of m_artist to the "--ta" param. And that's it! Making the FileAnalyzer class "dumb", by having it dump everything into a Map, would require scattering the actual processing of metainfo among all the Encoder classes - bad code design, IMHO.

soneca
17th January 2015, 19:10
It would be very difficult to implement an access to a database to LameXP and thus choose from such information to this database?

LoRd_MuldeR
17th January 2015, 22:19
It would be very difficult to implement an access to a database to LameXP and thus choose from such information to this database?

You mean like Gracenote or FreeDB? :confused:

I haven't digged into this topic enough to give a definite answer. I would have to see what kind of API these services offer and whether we can use them 100% free of charges. Somehow they need to "analyze" the audio file in order to be able to determine the meta info. So, if their API requires access to the "raw" (uncompressed) audio data to do the required analysis, it probably wouldn't fit into LameXP. That's because LameXP doesn't actually decompress the input audio files until they are actually converted. And if they require the application to compute some kind of "fingerprint" which is then sent to the web-server for analysis, then it all would depend on how exactly that fingerprint has to be computed...

soneca
18th January 2015, 01:19
You mean like Gracenote or FreeDB? :confused:

That's it!
But not to analyze file by file, but the cd's as a whole, the commercial albums.
As the plugin (http://www.cuetools.net/wiki/CTDB_EAC_Plugin) (CTBD) of Cuetools for example.

LoRd_MuldeR
25th January 2015, 19:14
LameXP v4.11 Beta-14
http://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2015-01-25/LameXP-BETA.2015-01-25.Release-Static.Build-1674.exe/download

Changes between v4.10 and v4.11 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2013 with Update-4
* Starting with this version, LameXP is based on the MUtilities (http://sourceforge.net/p/mutilities/code/) library + massive code clean-up
* Updated MediaInfo to v0.7.72 (2015-01-07), compiled with ICL 15.0 and MSVC 12.0
* Updated SoX to v14.4.2-Git (2012-10-06), compiled with ICL 15.0 and MSVC 12.0
* Updated Opus libraries to v1.1.x and Opus-Tools v0.1.9 to latest Git Master (2014-10-04)
* Updated mpg123 decoder to v1.21.0 (2014-10-11), compiled with GCC 4.9.1
* Updated Vorbis encoder to OggEnc v2.87 (2014-06-24), using libvorbis v1.3.4 and aoTuV b6.03_2014
* Updated Vorbis decoder to OggDec v1.10.1 (2014-06-25), using libVorbis v1.3.4
* Updated FLAC encoder/decoder to v1.3.1 (2014-11-26), compiled with ICL 15.0 and MSVC 12.0
* Updated GnuPG to v1.4.18 (2014-06-30), compiled with GCC 4.9.1
* Updated QAAC add-in to the latest to QAAC v2.44, including a fix (https://github.com/nu774/qaac/commit/ad1e0ea9daed076531e96cfa3b82f290ba9eeb20) for the --artwork option
* Fixed potential crash in Cue Sheet importer (occurred when all input files were missing)
* Fixed a severe performance bottleneck, especially with a large number of parallel instances
* Fixed a very rare problem that, occasionally, prevented the TEMP folder from being removed
* The limit for the maximum number of parallel instances has been increased to 32
* Experimental support for Windows 10 Technical Preview

mike20021969
25th January 2015, 20:08
Is there a new stable round the corner?

SeeMoreDigital
25th January 2015, 20:15
Hello,

Microsoft have just released a new version of Win 10 Pro (Build 9926). And now when I run LameXP I see the following: -

http://i62.tinypic.com/30asuaf.png

Sufficed to say, after pressing the 'ok' button, LameXP runs okay...


Cheers

LoRd_MuldeR
25th January 2015, 20:29
Microsoft have just released a new version of Win 10 Pro (Build 9926). And now when I run LameXP I see the following

http://www.en.kolobok.us/smiles/big_madhouse/dash2.gif

So, "Windows 7" is 6.1, "Windows 8" is 6.2, "Windows 8.1" is 6.3, but "Windows 10" is... 10.0 - at least in the latest preview build, it appears!

Order #1 for all Microsoft employees:
Invent the most stupid and inconsistent versioning scheme and, once everybody has gotten used to it and has implemented the required workarounds, let's break it once again by making it "sane" all of a sudden :mad:

Anyway, I will fix it for the next build. Also the mixed up title/text in that message box...

Is there a new stable round the corner?

Yes, but there are a few things that I want to address first. Also, my free time is more limited than ever before now. So there is no ETA yet...

mike20021969
25th January 2015, 20:46
Yes, but there are a few things that I want to address first. Also, my free time is more limited than ever before now. So there is no ETA yet...

No worries. Thanks.

:thanks:

Dogway
10th February 2015, 15:09
After a year your program becomes a PITA, showing a warning that I need to update, a stupid music sounds, and 10 seconds of my life down the drain.

Pair that with the (again) stupid decision of auto-labeling the output files, and you start to wonder if programmers want to ease your life or make it more complicated.

I leave this here so people know what to abide by. I think I am going back to a version prior to this "feature" (if there was one).

manolito
10th February 2015, 16:15
After a year your program becomes a PITA, showing a warning that I need to update, a stupid music sounds, and 10 seconds of my life down the drain.

I have to agree... :p

LameXP has an option to deactivate all update reminders. When I have selected this option then I really really do not want to be reminded for updates, even after more than a year.


Cheers
manolito

LoRd_MuldeR
10th February 2015, 19:47
After a year your program becomes a PITA, showing a warning that I need to update, a stupid music sounds, and 10 seconds of my life down the drain.

Pair that with the (again) stupid decision of auto-labeling the output files, and you start to wonder if programmers want to ease your life or make it more complicated.

I leave this here so people know what to abide by. I think I am going back to a version prior to this "feature" (if there was one).

Sigh. Yes, if (and only if) you have not updated the program for more than a whole year, then the update reminder becomes little more emphatic. And that is intentionally! People tend to be lazy when it comes to updates, so a little "motivation" is needed. If you really think that spending three minutes for updating the program once per year is asking too much - and let's not forget that the user interaction required during the update process is next to nothing - then I'm out of ideas.

Why would you want to stick with a version that is more than year old? During this year a lot of effort has been made to further improve the program. Why do you want to ignore all these efforts? If there is any understandable reason to stick with an outdated version, then it would be regressions in the current version. But, in that case, I highly recommend that you report the regressions which you have encountered, so that we can (hopefully) sort them out ASAP.

Last but not least, remember that is FOSS (http://de.wikipedia.org/wiki/Free/Libre_Open_Source_Software). So if you REALLY wanted to permanently stick with an old version for whatever reason, or should development ever be discontinued (which I currently have no plans for!), then you could simply remove the update reminder from the source code. I won't give you any specifics (and I beg others to not do this either!), but the required change would be minimal. Even with rudimentary programming skills you could figure this out in a minute or so.


(Addendum: There are various "freeware" sites out there, which are still distributing versions of my software that are many years old! These versions don't represent the current development state of the software at all and I don't want people to get the wrong impression. Consequently, we need to make sure that even those people, which happen to stumble upon an extremely old version of the program, will quickly be "upgraded" to a somewhat recent version)

SeeMoreDigital
10th February 2015, 22:14
Jeez...

Don't you just love people who moan about 'free-ware' software. Yep, you just want to get-out there and give them all a big squishy hug... Yep, you really do!

Dogway
11th February 2015, 05:10
Thanks this is not a dictatorship and I can voice my opinion : )
That's why I will state the same words in the videohelp review comments. You @SeeMoreDigital are free to like or dislike them, but I will just say, this is the first time in my life a program insists on updating so annoyingly. I'm sorry for not being in the OCD update spiral, some people simply know when enough is good enough.

LoRd_MuldeR
11th February 2015, 20:20
You are free to express your opinion. But I think you are way exaggerating things here. You still haven't explained what exactly you are complaining about: Why are you refusing to update to a somewhat reason version so eagerly? I assume that it can not be because the update process takes too long or because it is too much complicated - this can almost certainly be excluded. So it leaves two options: Either you want to stick with the deprecated version, because the new version has some problem that didn't exist in the old version, or you are complaining for purely "ideological" reasons. In the former case, I suggest you report the problem, so we (hopefully) can sort it out. In the latter case there is no way to make it right for you.

BTW: It is perfectly normal that software products will reach "end of life" after a certain period, at which point an update to a recent version is obligatory. Only that with most commercial products you'll have to pay to get an up-to-date version, while LameXP is free software and thus the update is offered to you 100% free of charge. Most people know how to appreciate this service.

Dogway
11th February 2015, 21:52
"so we can...", mandatory updates, EOL, 100% free of charge, service... isn't that a bit of megalomaniac? There's more than black or white, it's for both reasons, and I wrote them as a review in VideoHelp. I'm not going to ask or bug report (complain in you vocabulary) anything anymore after the way I was treated here before (censored and banned). I haven't seen you give in a single thing anyone told you in this thread, that speaks for itself.

I came only to let people know about the infamous 1 year update reminder.
At least and surprisingly is open-source, so that's something.

LoRd_MuldeR
11th February 2015, 22:28
"so we can...", mandatory updates, EOL, 100% free of charge, service... isn't that a bit of megalomaniac?

Yeah, developing a software in your free time over a period of 10+ years and offering that software to everybody 100% free of charge is... megalomaniac :rolleyes:

(If somebody offers free vanilla ice to you on a hot summer day, you are probably going to complain that you like chocolate better and ask why that moron does not offer chocolate ice for free)

I came only to let people know about the infamous 1 year update reminder.
At least and surprisingly is open-source, so that's something.

You are complaining about something that only happens under extremely rare circumstances, i.e. when somebody really hasn't update the software for more than a whole year. Something that a responsible-minded user, who at least makes some effort to keep his software up-to-date, is never going to see. And, despite all of this, you a trying make it sound as if it was such a "big" affair - while in fact it's barely worth mentioning. Finally, you haven't been able to give any kind of explanation why in the world you are so eagerly refusing to update to a somewhat recent version. Consequently, I'm just going to take this for what it is: Complaining as a pastime, with no honest interest in resolving or improving anything.

(Telling the world that this software is going to remind you that you haven't updated your software for more than a whole year, iff indeed you haven't updated your software for more than a whole year, is like announcing that the sky is blue)

Dogway
11th February 2015, 22:44
You seem to ignore the fact that a program update, like new programs can be "game changers". That in a production environment is consumed time (for learning the new rules), and that equals to money. Maybe NASA prefers using DOS based OS, banks are content with XP, and some users are fine using a certain program build because they have no time to update the 200 programs they have on their computer, or simply fits their necessities.
You don't have to make a fuss of it, I came here, voiced my opinion, over. There's no more to it. Learn to accept critics, or opinions ("complains" in your vocabulary).

LoRd_MuldeR
11th February 2015, 22:59
You are not criticizing anything, that's the problem! When asked why exactly you eagerly want to stick with the old outdated version and/or what problems are preventing you from using the up-to-date version, you are not delivering any explanations whatsoever. Thus I have to assume that you haven't even tried the new version. So you are obviously not interested in getting any real problems fixed, because you have not encountered any real problem. Instead, you are complaining that the program is reminding you that you missed updating the program for more than a whole year, when indeed you missed updating the program for more than a whole year. This is like hurting yourself with a hammer and then complaining that it hurts! :rolleyes:

So either report a real problem, make a constructive suggestion, or stop flooding this thread...

foxyshadis
12th February 2015, 00:11
Given the amount of choice in open source audio apps, the easiest solution to disliking a developer's personal style is to use another. It should be obvious by now that arguing about unusual design decisions won't ever change Mulder's mind, and that's a general truism for any single-developer software, no matter how right you think you are. It's their baby, after all.

Move on, let it go, you literally can't win.

LoRd_MuldeR
12th February 2015, 01:36
It should be obvious by now that arguing about unusual design decisions won't ever change Mulder's mind, and that's a general truism for any single-developer software, no matter how right you think you are. It's their baby, after all.

Move on, let it go, you literally can't win.

:rolleyes:

To make it clear: It's perfectly okay, if somebody expresses a different opinion. And if he/she has convincing arguments, I have no problem with accepting suggestions, as it has happened so many times before. But it definitely is not acceptable, if somebody comes along and proclaims what is "wrong" in my software, as if his opinion was a fact (which it is not!), or what I ought to change in my software, as if he was my boss (which he is not!). Furthermore, if he actually came here with goal to improve the software (not just for ranting), he would try convince me. And you convince people with convincing arguments. You do not convince people by repeating the same complaints over and over again, while refusing to provide any details. You do not convince people by ignoring explanations that have been given to you. And you certainly do not convince people by blackmail ("either you do what I want or I'm going to spread defamation about your software"). More than enough said.

LoRd_MuldeR
17th February 2015, 21:17
LameXP v4.11 RC-1
http://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2015-02-17/LameXP-RC1.2015-02-17.Release-Static.Build-1678.exe/download

Changes between v4.10 and v4.11 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2013 with Update-4
* Updated Qt runtime libraries to v4.8.7 snapshot-4 (2015-02-16), compiled with MSVC 12.0
* Starting with this version, LameXP is based on the MUtilities library + massive code clean-up
* Updated MediaInfo to v0.7.72 (2015-01-07), compiled with ICL 15.0 and MSVC 12.0
* Updated SoX to v14.4.2-Git (2012-10-06), compiled with ICL 15.0 and MSVC 12.0
* Updated Opus libraries to v1.1.x and Opus-Tools v0.1.9 to latest Git Master (2014-10-04)
* Updated mpg123 decoder to v1.21.0 (2014-10-11), compiled with GCC 4.9.1
* Updated Vorbis encoder to OggEnc v2.87 (2014-06-24), using libvorbis v1.3.4 and aoTuV b6.03_2014
* Updated Vorbis decoder to OggDec v1.10.1 (2014-06-25), using libVorbis v1.3.4
* Updated FLAC encoder/decoder to v1.3.1 (2014-11-26), compiled with ICL 15.0 and MSVC 12.0
* Updated GnuPG to v1.4.18 (2014-06-30), compiled with GCC 4.9.1
* Updated QAAC add-in to the latest to QAAC v2.44, including a fix for the --artwork option
* Fixed potential crash in Cue Sheet importer (occurred when all input files were missing)
* Fixed a severe performance bottleneck, especially with a large number of parallel instances
* Fixed a very rare problem that, occasionally, prevented the TEMP folder from being removed
* The limit for the maximum number of parallel instances has been increased to 32
* Experimental support for Windows 10 Technical Preview

SeeMoreDigital
17th February 2015, 21:42
I'm happy to report that this version launches without any errors using Win 10 Pro (Build 9926) :)

kadajawi
27th February 2015, 17:01
Question: I want to convert the soundtrack of TV episodes into Opus, and they are in surround. The way I understand it the bitrate setting you use for Opus in LameXP is the overall bitrate... at which point having 256 kbit as the maximum is a bit low for 6 channels...? Any way to go higher?

LoRd_MuldeR
27th February 2015, 17:34
Question: I want to convert the soundtrack of TV episodes into Opus, and they are in surround. The way I understand it the bitrate setting you use for Opus in LameXP is the overall bitrate... at which point having 256 kbit as the maximum is a bit low for 6 channels...? Any way to go higher?

It's not currently possible. But I could allow for even higher Opus bitrate in future versions, if there actually is demand for it.

(BTW: Did you actually try 256 kbps for your source and result was not satisfying?)

kadajawi
27th February 2015, 20:57
It's not currently possible. But I could allow for even higher Opus bitrate in future versions, if there actually is demand for it.

(BTW: Did you actually try 256 kbps for your source and result was not satisfying?)

For multichannel content that would be nice. Currently I get around 40 kbit per channel, and that is too little. The same source with Ogg Vorbis q4 is around 380 kbit in total, and that's the quality I want. I could hear some artifacts, and that was on cheap speakers. I think with 320 kbit it should be fine, but 256 is too low IMHO. And imagine what happens with 7.2 audio sources...

SeeMoreDigital
28th February 2015, 16:01
For multichannel content that would be nice. Currently I get around 40 kbit per channel, and that is too little. The same source with Ogg Vorbis q4 is around 380 kbit in total, and that's the quality I want. I could hear some artifacts, and that was on cheap speakers. I think with 320 kbit it should be fine, but 256 is too low IMHO. And imagine what happens with 7.2 audio sources...With regard to 5.1 channel encodes. Have you tried using HE-AAC between 192Kbps and 256Kbps?

GMJCZP
8th March 2015, 18:25
LoRd_MuldeR, for CD ripping you recommend CUE Tools, Does the program fre:ac is equivalent? Thanks.

LoRd_MuldeR
8th March 2015, 18:34
LoRd_MuldeR, for CD ripping you recommend CUE Tools
Do I? :confused:

Actually I use Exact Audio Copy (EAC) when I need to rip one of my Audio-CD's.

Does the program fre:ac is equivalent? Thanks.
Since I don't use fre:ac, so I cannot say much about it.

But since it's a fully-fledged audio converter, I guess you would use either LameXP or fre:ac. You probably wouldn't use fre:ac for ripping your Audio-CD just to convert with LameXP afterwards ;)

Anyway, whether the "ripping" capabilities of fre:ac are on par with EAC, I have no idea...

GMJCZP
8th March 2015, 18:52
Do I? :confused:

Actually I use Exact Audio Copy (EAC) when I need to rip one of my Audio-CD's.


Sorry for my confusion, it was EAC and not Cue Tools, lol.
Thanks for your reply LoRd_MuldeR.

I know this question is already out of the post, but someone will clarify whether fre:ac is usable as EAC or Cue Tools for CD ripping?

LoRd_MuldeR
8th March 2015, 20:21
I know this question is already out of the post, but someone will clarify whether fre:ac is usable as EAC or Cue Tools for CD ripping?

I don't know whether fre:ac uses any "external" program (or a specific library) for Audio CD ripping or whether it does this all by itself.

You probably want to ask the fre:ac author ;)

soneca
10th March 2015, 17:52
Sorry for my confusion, it was EAC and not Cue Tools, lol.
Thanks for your reply LoRd_MuldeR.

I know this question is already out of the post, but someone will clarify whether fre:ac is usable as EAC or Cue Tools for CD ripping?

If you want to extract also CDs scratched, those who are not in good condition recommend using programs like EAC, dBpoweramp and CUERipper to use secure mode to check and try to correct the errors and also extra verification by AccurateRip.
fre:ac would be more appropriate only for conversion between formats.

SeeMoreDigital
19th March 2015, 18:08
Oh no... My binary has expired... It's the end of the world :eek:

lethedoom
20th March 2015, 00:10
Mine Too. Back to still reliable 4.10 final until further development of 4.11 is made available.

Przemek_Sperling
20th March 2015, 10:34
Amen, brother, amen.

Andouille
20th March 2015, 11:23
Oh no... My binary has expired... It's the end of the world :eek:

Mine has expired 5 years ago (v3.18)...
I just have to click "OK" two times more and it works...

LoRd_MuldeR
21st March 2015, 00:04
Oh no... My binary has expired... It's the end of the world :eek:

Sorry, usually I will upload a new test build before the previous test build has expired.

However, this week I have been on a business trip, so no access to my development machine, ultra-slow hotel Internet connection, and no time anyway.

New build will be available soon, but I'll need to catch a snatch of sleep now ;)

Przemek_Sperling
21st March 2015, 08:39
So sleep well :-)

LoRd_MuldeR
21st March 2015, 20:07
LameXP v4.11 RC-3

Changes between v4.10 and v4.11 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2013 with Update-4
* Starting with this version, LameXP is based on the MUtilities (http://sourceforge.net/p/mutilities/code/) library + massive code clean-up
* Added support for the DynamicAudioNormalizer (https://github.com/lordmulder/DynamicAudioNormalizer) normalization filter
* Updated Qt runtime libraries to v4.8.7 snapshot-4 (2015-02-16), compiled with MSVC 12.0
* Updated MediaInfo to v0.7.72 (2015-01-07), compiled with ICL 15.0 and MSVC 12.0
* Updated SoX to v14.4.2-Final (2015-02-22), compiled with ICL 15.0 and MSVC 12.0
* Updated Opus libraries to v1.1.x and Opus-Tools v0.1.9 to latest Git Master (2014-10-04)
* Updated mpg123 decoder to v1.22.0 (2015-02-24), compiled with GCC 4.9.2
* Updated Vorbis encoder to OggEnc v2.87 (2014-06-24), using libvorbis v1.3.4 and aoTuV b6.03_2014
* Updated Vorbis decoder to OggDec v1.10.1 (2014-06-25), using libVorbis v1.3.4
* Updated FLAC encoder/decoder to v1.3.1 (2014-11-26), compiled with ICL 15.0 and MSVC 12.0
* Updated GnuPG to v1.4.18 (2014-06-30), compiled with GCC 4.9.1
* Updated QAAC add-in to the latest to QAAC v2.44, including a fix for the --artwork option
* Fixed potential crash in Cue Sheet importer (occurred when all input files were missing)
* Fixed a severe performance bottleneck, especially with a large number of parallel instances
* Fixed a very rare problem that, occasionally, prevented the TEMP folder from being removed
* The limit for the maximum number of parallel instances has been increased to 32
* Experimental support for Windows 10 Technical Preview
* Updated language files (big thank-you to all contributors !!!)

SeeMoreDigital
21st March 2015, 20:13
Woohoo! The world is re-born :D

manolito
22nd March 2015, 16:57
Thanks very much for the RC3 version... :thanks:

Did a couple of tests (still my old WinXP on a non-SSE2 CPU), and I found only one bug. :devil:

The latest LameXP.qaac-addin.2014-01-19.zip does not work with the current Apple Application Support version. The AAC encoder is simply not recognized. It is necessary to use a newer qaac.exe version in the LameXP folder, the version from this archive does work:
https://yadi.sk/d/IaHUQp7wen9uX

Otherwise no problems at all, special thanks for still supporting my CPU (of course still need to switch to 16 bit colors).

And even the patched SoX version with integrated DynamicAudioNormalizer does not require SSE2 (as opposed to the version which ships with DynamicAudioNormalizer), much appreciated... :)

I also like the revamped audio normalizing setup, the channel coupling option is much more intuitive than the former method.


Thanks again,
Cheers
manolito

LoRd_MuldeR
22nd March 2015, 17:11
The latest LameXP.qaac-addin.2014-01-19.zip does not work with the current Apple Application Support version. The AAC encoder is simply not recognized. It is necessary to use a newer qaac.exe version in the LameXP folder, the version from this archive does work:
https://yadi.sk/d/IaHUQp7wen9uX

Interesting ;)

I had a quick look at QAAC changelog and could not find a change (since the 2014-12-25 (http://sourceforge.net/projects/lamexp/files/Miscellaneous/Add-ins/qaac/Testing/LameXP.qaac-addin.2014-12-25.zip/download) build) that explicitly addresses Apple Application Support compatibility:
https://github.com/nu774/qaac/commits/master

Anyway, I can try to make a fresh QAAC build from Git Master and we can check if that helps.

BTW: What version of Apple Application Support are you using and how can I get it? What is the newest version that still works with "my" QAAC binary?

manolito
22nd March 2015, 17:52
BTW: What version of Apple Application Support are you using and how can I get it? What is the newest version that still works with "my" QAAC binary?

I used the current version 2.3.6 dated from 07.10.2014. I extracted it from the current QuickTime installer.

I normally do not use Apple Application Support because it is a little too snoopy for my taste. I use portable qaac versions instead like the one from my link. But for testing the latest LameXP version I cleaned up everything and installed the qaac addon and Apple Application Support exactly like explained in the manual. And I only got it to work after replacing qaac.exe with the newer version.


Cheers
manolito

LoRd_MuldeR
22nd March 2015, 18:19
I used the current version 2.3.6 dated from 07.10.2014. I extracted it from the current QuickTime installer.

I tried with Apple Application Support version 3.1.2 (containing CoreAudioToolbox version 7.9.9.6) and it worked fine for me with latest QAAC Add-in for LameXP (2014-12-25) :confused:

Apple Application Support → https://www.sendspace.com/file/njfor9
QAAC Add-in for LameXP → http://sourceforge.net/projects/lamexp/files/Miscellaneous/Add-ins/qaac/Deprecated/LameXP.qaac-addin.2014-12-25.zip/download


Anyway, I am going to make a build of the the latest QAAC version now, just to be sure we aren't missing anything...

LoRd_MuldeR
22nd March 2015, 20:26
Updated QAAC Add-in for LameXP, based on QAAC v2.47 (2014-02-15)
http://sourceforge.net/projects/lamexp/files/Miscellaneous/Add-ins/qaac/Testing/LameXP.qaac-addin.2015-03-22.zip/download