Re: [Musicpd-dev-team] libcue licensing problem
Hi Max, Max Kellermann wrote: Avuton forwarded a mail from Svend Sorensen to me: On Wed, Apr 22, 2009 at 10:53 AM, Svend Sorensen sv...@ciffer.net wrote: Did you give permission to change the license to libcue[1]? I did not. Jochen Keil sent me an email asking if he could relicense parts of cuetools under a BSD license, but I never got around to replying. That's nice that he found the time to answer Avuton.. Until today (23.04.09) i did not receive *any* mail from Svend. What's wrong with the old license? While this is basically your own personal problem GPL is to restrictive *imho*. http://www.freebsd.org/doc/en/articles/bsdl-gpl/article.html You didn't respond to my former questions regarding that license change Honestly, i can't recall those.. code from MPD on 30th of April (7 days from now), unless you can convince me that your code is legal. I'm tempted to say go for it, then take down everything on sf and leave everyone else in the dust. I've got my stuff here, why should i care to share it? I'm really upset about this. What is going on here behind my back? However, there is a modified COPYRIGHT notice as well as some updated copyright notifications in several files in the git repo on sf.net. Please have a look and tell me if you are fine with it. Jochen signature.asc Description: OpenPGP digital signature -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] libcue licensing problem
Hi Max, Max Kellermann wrote: Nothing is going on behind your back. I asked you half a dozen of times on IRC to clean up your licensing problem, and others also pointed out that you're violating Svend's copyright. Since you didn't respond to any of those, Avuton asked Svend instead. i don't want to argue about that with you but i told everyone that i sent an email and never got a reply. I don't understand why Svend replied to Avuton instead of me, doesn't he like my email address? Please understand that you must not change the license of somebody else's work without his permission. Getting no response simply means no! That's not a valid excuse. Since the copyright hasn't been updated for almost two years now, i felt more like this is abandoned code. What this implies legally is of my scope as i'm not a lawyer. It might well have been a mistake to just relicence it to BSD but i had to make a decision. What's more important: i never ever wanted to steal someones work nor label it as mine. That's why i imported the whole cuetools repo, made the work to transparently move every source file and keep all the copyright notices where appropriate. 'Copyright (c) 2009, Jochen Keil' marks code which is released as 2-clause BSD license You added your name to all source files, even those which you didn't That's why i added this: (and only with this notice alone, if there is an additional copyright notice about Svend Sorensen, GPL applies!) touch at all (e.g. time.c). That's been a careless copy and paste error. I fixed it now, thanks for your remark. Suggestion: add the full BSD license to all files which you created (e.g. rem.c), and all others stay 100% GPL according to COPYING, even if you modified them. That's a good idea and i applied it. One last thing i'd like to add. There have been a lot of modifications done by me. Some may be trivial but some are quite under the hood and fixed severe mistakes. If it weren't for the lexer (tokenizer) or the parser (grammar) i might have written this as well myself. Unfortunately there is not much room left for writing the tokenizer/grammar in a different way in lex/yacc. All in all i'm not happy with GPL. I don't want to make a fuss here though since i think that it's more important to share the work so that everyone can benefit from it. All the updated copyright notices are now on git at sf.net. If there are no objections anymore i'll repackage the latest release asap. Jochen signature.asc Description: OpenPGP digital signature -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Support for parsing/tagging flac files according to embedded cuesheets
Hi Max, Max Kellermann wrote: It's important to document what was written by the original author and what was modified by you. Media players are a dangerous area (regarding copyright and patents), and we need to have a reliable audit trail of everything, just in case. I understand that and agree with you on that issue. So what i've done is this: I've built a shared library based on cuetools. I want to re-release this stuff as libcue on sourceforge or whereever so we only need to install and link mpd against it. I already contacted Svend about this. If he is willing to let me relicence it as BSD software, i'll do so. Otherwise i'd have to go with GPL but that wouldn't hurt either i think. Now i'm reading about automake/autoconf so i have a build system for the initial/first/alpha release.. :) Enjoy your holidays. Regards, Jochen signature.asc Description: OpenPGP digital signature -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] embedded cue sheets in flac files (recently added to repository)
Hi Mario Lenz wrote: So a non- standard solution involving a complex task like developing a cuesheet parser is superior to another non- standard solution that simply changes a handfull of lines in your code? If you consider this a complex task than this must not mean that it's a difficult job for someone else. Writing a parser in lex/yacc is far superior and easier to do than a bunch of strcmp's nested in if statements. Despite that you might want to take a look at this: http://digitalx.org/cuesheetsyntax.php and http://developer.berlios.de/docman/display_doc.php?docid=517group_id=2130 This may not be a defined standard but it's well documented, on a common base and everybody sticks to it. What other players support parsing this CUESHEET tag? foobar2000 metaflac 1.2.1 doesn't. $ metaflac --version metaflac 1.2.1 You should check your installation. Regards, Jochen signature.asc Description: OpenPGP digital signature -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Flac embedded cuesheet support
Hi Max, Max Kellermann wrote: Do you know of a better way/have a better idea for enumerating the subtracks instead of track_xxx.flac like i did atm? No, although I'd probably just call it 1, 2, ... without any prefix/suffix. I figured with the prefix the files get sorted in a correct order.. but this is cosmetical and should be configurable as soon as we have cue sheet support. For now, we could say: those virtual sub-songs can only be one level above the main song (which is enough for supporting CUE). So if the file cannot be found, try its parent. If that's a file, handled by a decoder plugin which can handle sub-songs, call method sub_decode() (instead of file_decode()?). Just an idea. So we would have two new api extensions: sub_decode() and scan_directory()? That's ok for me and i'll implement it that way. This should be no problem with the scan_directory api extension. Though i now have to include tag.h, song.h, songvec.h and dirvec.h to flac_plugin.c. Is this ok? Doesn't sound perfect yet, but good enough for now. We could make the scan_directory() method point to the flac_cue_track() method and extend the the tag_dup method to tag the (virtual) files accordingly. That way the code would be separated i think and the includes shouldn't be necessary anymore. 3) Write an parser on your own. Doesn't look too hard, does it? If we write a good library, others might adopt it in the future... that'll be the first CUE library with a decent API then. Hm.. i think it would be a bit hard for me but i got used to C the last weeks so it could be done i guess (also it'd take some time..). The more general problem is that i do not really have a clue about writing a parser. I figured to make something like a fixed size hash table according to the entrys (like PERFORMER, TRACK, etc.) and then have a linked list with entrys attached to the table (similar to separate chaining). But maybe there's a whole different general approach to parsing i am not aware of. Maybe we can fork the cuetools library? There are some good parts which could be used but the parser itself is written in yacc/bison which i don't speak. :) Regards, Jochen signature.asc Description: OpenPGP digital signature -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Flac embedded cuesheet support
Hello Max, Max Kellermann wrote: It's a hack, but I think if we cut off some rough edges, we can merge it anyway. Let's get the feature in if it doesn't break anything, and think about migrating to a clean solution after that. Currently i'm working on the scan_directory() method you proposed in one of your first emails. This isn't to hard to do now and we'll get rid of several include dependencies. Do you know of a better way/have a better idea for enumerating the subtracks instead of track_xxx.flac like i did atm? diff --git a/src/input_file.c b/src/input_file.c index b29a412..cd3f2e7 100644 --- a/src/input_file.c +++ b/src/input_file.c @@ -25,6 +25,9 @@ #include string.h #include glib.h +#include ls.h +#include decoder/_flac_common.h + MPD core sources should not include decoder specific headers. But now I understand what you meant with input_flac on IRC - it'll eliminate this dependency. Would it be better if i did something like this: stat() the pathname on NULL: go one level below stat() again until we're either root or have a file. (haven't tried it yet, maybe i'm wrong on this but after a quick look in input_file.c i think this might work as well) diff --git a/src/update.c b/src/update.c index 17059ff..9599e9a 100644 --- a/src/update.c +++ b/src/update.c @@ -35,6 +35,9 @@ #include stats.h #include main.h #include config.h +#include tag.h + +#include decoder/_flac_common.h Same here, although that will be more difficult to get rid of. Let's say you add #ifdef HAVE_FLAC around that code, and we merge it - cleanup (decoder API extension) later. This should be no problem with the scan_directory api extension. Though i now have to include tag.h, song.h, songvec.h and dirvec.h to flac_plugin.c. Is this ok? The general approach of scan_directory could be used for the archive plugin as well i think.. We had a short talk about the cue sheet support on irc. This is going to be a pita imho. :) 1) cuetools are from 2006 and take only a fd as input A possible solution would be to write out embedded cue sheets (like in flacs) to a temporary file with mkstemp() (libc) and use that for i/o. 2) cdrecord has a cue sheet parser. This also takes an fd and it's not a library so using it could become quite difficult. Whatsmore it another ~1250 lines monster i cannot rewrite easily.. This gets me to 3) Write an parser on your own. Here you can find the complete spec: http://digitalx.org/cuesheetsyntax.php As you can see (and also from cuetools/cdrecord) this ain't an easy thing to do. 4) Use a parser lib written in e.g. in C#: http://wyday.com/cuesharp/ Do you really want that? :) As a conclusion for the cue parser/plugin: Writing a parser ourselves would be the best option but also the hardest. I tend to like the cuetools approach best because the specs didn't change and cuetools seem to be usable in an easy way. What i don't like though is having a tmp file.. Looking forward to your reply and greets, Jochen signature.asc Description: OpenPGP digital signature -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Flac embedded cuesheet support
Hello Max,
as promised i send the patch against the latest git sources (cloned on
Mo 23 Feb 2009 10:57:36 CET).
This will add support for embedded cue sheets in flac files.
Please send me any comments for improvement, critisim or bugs.
I have commented some parts where i think more work has to be done.
Whatsmore i'm not so happy with it overall, to me it seems more like a
hack rather then something clean.. anyway for the moment it's the best i
can do.
Hope you like it anyway. ;)
Any hints where i could get started to get the subsongs proper tagged?
Max Kellermann wrote:
If you're developing only for the new libflac API
(FLAC_API_VERSION_CURRENT 7), then you don't need any macros, but be
sure your code won't be compiled on older libflac APIs. There are
still people around using those ancient versions..
For the moment my patch isn't #defined for FLAC 7 but i'll change that
asap.
One last question:
Is there a way to access song-tag from the decoder plugin (flac_plugin.c)?
Trying access decoder-stream_tag or decoder-decoder_tag doesn't
work/wouldn't even compile.
Thanks and regards,
Jochen
diff --git a/src/decoder/_flac_common.c b/src/decoder/_flac_common.c
index 63dc6e1..7dd0b8a 100644
--- a/src/decoder/_flac_common.c
+++ b/src/decoder/_flac_common.c
@@ -345,3 +345,97 @@ flac_common_write(struct flac_data *data, const
FLAC__Frame * frame,
return FLAC__STREAM_DECODER_WRITE_STATUS_CONTINUE;
}
+
+char*
+flac_cue_track(const char* pathname,
+ const uint8_t tnum)
+{
+ FLAC__StreamMetadata* cs =
FLAC__metadata_object_new(FLAC__METADATA_TYPE_CUESHEET);
+
+ FLAC__metadata_get_cuesheet(pathname, cs);
+
+ if (cs == NULL)
+ return NULL;
+
+ if (cs-data.cue_sheet.num_tracks = 1)
+ {
+ FLAC__metadata_object_delete(cs);
+ return NULL;
+ }
+
+ if (tnum 0 tnum cs-data.cue_sheet.num_tracks)
+ {
+ char* track = g_malloc(sizeof(char));
+ if (tnum 10)
+ sprintf(track, track_00%ld.flac, (long)tnum);
+
+ else if (tnum = 10)
+ sprintf(track, track_0%ld.flac, (long)tnum);
+
+ else if (tnum = 100)
+ sprintf(track, track_%ld.flac, (long)tnum);
+
+ FLAC__metadata_object_delete(cs);
+
+ return track;
+ }
+ else
+ {
+ FLAC__metadata_object_delete(cs);
+ return NULL;
+ }
+}
+
+const char*
+flac_get_basename(const char* pathname)
+{
+ uint8_t tnum = 0;
+ char* ptr = NULL;
+ char* ptr_ = NULL;
+ char* ptrdot = NULL;
+ const char* filename;
+
+ FLAC__StreamMetadata* cs;
+
+ cs = FLAC__metadata_object_new(FLAC__METADATA_TYPE_CUESHEET);
+
+ FLAC__metadata_get_cuesheet(pathname, cs);
+
+ filename = strdup(pathname);
+
+ if (cs == NULL)
+ {
+ // last '/' in pathname: ++ptr should now start at
'track_xxx.flac'
+ ptr = strrchr(filename, '/');
+ *ptr = '\0';
+
+ // underscore in 'track_xxx.flac'; ++ptr_ = 'xxx.flac'
+ ptr_ = strrchr(++ptr, '_');
+ *ptr_ = '\0';
+
+ // ++ptrdot should start at 'flac'
+ ptrdot = strrchr(++ptr_, '.');
+ *ptrdot = '\0';
+
+ tnum = strtol(ptr_, NULL, 10);
+
+ if (strcmp(ptr, track) == 0
+ strcmp(++ptrdot, flac) == 0
+ tnum 0 tnum 255)
+ {
+ g_debug(return filename: %s, filename);
+ return filename;
+ }
+ else
+ return NULL;
+ }
+ else
+ return pathname;
+}
+
+void
+flac_cue_tag_song(struct tag* tag, const uint8_t tnum)
+{
+ //tag = NULL;
+ //tnum = 0;
+}
diff --git a/src/decoder/_flac_common.h b/src/decoder/_flac_common.h
index e876c35..cbbc496 100644
--- a/src/decoder/_flac_common.h
+++ b/src/decoder/_flac_common.h
@@ -175,4 +175,17 @@ FLAC__StreamDecoderWriteStatus
flac_common_write(struct flac_data *data, const FLAC__Frame * frame,
const FLAC__int32 *const buf[]);
+char*
+flac_cue_track(const char* pathname,
+ const uint8_t tnum);
+
+const char*
+flac_get_basename(const char* pathname);
+
+void
+flac_check_cue_track(struct tag* tag, const uint8_t tnum);
+
+void
+flac_cue_tag_song(struct tag* tag, const uint8_t tnum);
+
#endif /* _FLAC_COMMON_H */
diff --git a/src/decoder/flac_plugin.c b/src/decoder/flac_plugin.c
index ce056d2..6a44479 100644
--- a/src/decoder/flac_plugin.c
+++ b/src/decoder/flac_plugin.c
@@ -382,6 +382,233 @@ flac_decode(struct decoder * decoder, struct input_stream
*input_stream)
#ifndef HAVE_OGGFLAC
+/*
+ * @brief Open a flac file for decoding
+ * @param fname filename on fs
