Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[JimH]

[jctcom]

Ok.  I will have to look for another album with Headers on Discogs that I need to update.  I will post back when I get there.

Carl.

[jctcom]

Found another anomoly for you.  Not sure how you would tackle this though.

If you look at the following release:

http://www.discogs.com/JS-Bach-Yo-Yo-Ma-The-Six-Unaccompanied-Cello-Suites-6-Suiten-F%C3%BCr-Violoncello-Les-6-Suites-Pour-Viol/release/999363

You will see the track numbers are numbered:  1.01, 1.02, 1.03,,, 2.01,2.02, 2.03 and so on.

The discogs.pl took all those 1's and 2's at the beginning of each track number and used those as the track numbers. So you end up with 18 track 1's and 18 track 2's. 

I think the problem is that Discogs does not seem to have a fixed convention for numbering multi-disc sets.
Sometimes it is D1-01 and sometimes like above and I think sometimes different from those depending on who made the entry.

But it did ignore all the headers nicely.

Have fun.

Carl.

[MrC]

Thanks for the link.  I'll take care of this tomorrow, it's an easy enough fix.  I knew there would be variations on how disc/tracks were presented.

This is also a good case where the headers might be useful; maybe they can be optionally stored in some other field, or prefix the track title, since having n different "Prélude" tracks is not so interesting.

[jctcom]

Yeah that would be nice.

The only problem I see is that they aren't used any any real consistent manner on Discogs. (and probably most other places)

btw.  I don't do much classical music.  The cataloging of them seems quite daunting.  What do people do with all those meaningless (To me lol) numbers etc...  This one was actually fairly straight forward.  Like you I just added the headers to the beginning of the tracks.  But some of those numbers and designations can be quite long making for an unreasonably long title when it comes to renaming the tracks etc...

Carl.

[MrC]

Build 1.05 is now posted.

Version 1.05 Changes:
    - Fix: key 'date' is pulled from the master entry, so it is the original date of the album, not the
      release date (which is 'rdate').
    - Fix: incorrect track names and total track count when the tracklist contains header information.
    - Fix: some discogs entries use dot instead of dash as a disc/track separator.
    - New: key 'heading' mapped to Comments captures possible track headings in the discogs track list.
      A heading might contain the name of a particular work or grouping of tracks, for example:
      Suite No. 1, S. 1007 (G Major / G-dur / Sol Majeur).

[jctcom]

Hey MrC.

There is an issue with Headers / Comments which I don't think even you will be able to fix.  (How's that for a challenge eh?)

In looking at this album  (and I think many are the same)

http://www.discogs.com/Yes-Fly-From-Here/release/3075942

The Header only applies to the first 6 tracks on each of the LP and CD's there.

The problem is that there isn't actually anything to indicate where the header might stop applying if there is only one header on the album or disc.

In this particular case you could probably say it ends at the LP on the LP disc but not for the CD.

I will have to go through my discs to see what other albums might have Header's only for the first suite where they might not apply for the rest of the disc.  But I can tell you right now some good places to start will be Rush and other albums from Yes (Especially their early stuff)

Carl.

[jctcom]

I am guessing people will have to do 1 of 2 thngs.

Either edit out the Comments for the tracks that the headers don't apply to afterwards.

or do like this guy did:

http://www.discogs.com/Yes-Close-To-The-Edge/release/2689712

and edit the discogs entry to add an ending header so that the system knows when that header stops applying (and your program as well).  (Now wasn't that thoughtful of him  )

Carl

[MrC]

Garbage In, Garbage Out.

Headers are inaccurate if there is not some corresponding form of delineation separating items for which the headers do not apply.

[lepa]

Hi,
Just to report that --nodiscnum seems to add 0 to Disc #. It's only visible in MC if I choose art and music. MC then shows [varies] in the Disc # field. in Foobar2000 shows the zero as a disc number.

[JimH]

The view may not be showing Disc #, but you can add it by right clicking on the title bar at the top of the list.

[lepa]

The problem is that the field should be empty "" not "0"

[MrC]

This (Disc # == 0 issue) was introduced recently.   I have a dilemma.

In MC, there is no mechanism to clear a value via MCWS or MPL import, so a field that should have no value (such as Disc # for single disc albums) cannot be cleared.  If I do not set the value to 0, this leaves mis-tagged values incorrect; if I set the value to 0, an actual value of 0 is stored, but in the UI it appears as empty (since MC doesn't tightly distinguish between 0 and empty for numeric fields such as Disc # when using a field's display format).

What is really needed is a way to force the clearing of a field.   I'll post a request for this in the Beta forum.

In the meantime, I'll revert the change and not write out Disc # when --nodiscnum is set, or for single-disc albums.

[lepa]

I can also delete tag manually. This is such time saver script that it is no problem to do that. I just noticed this because art was not getting that zero and showed [varies] when every album files was selected (and well obviously in foobar2000 I noticed the zeros)

[MrC]

Let me get a fix out for you.  It is more important that you don't have to do more manual work, esp. since most albums are single-disc.  Just note that if you have incorrect disc # values now which should be cleared, the script can't do that for you and you'll have to correct those.

[MrC]

Version 1.06 is posted.  I only did brief testing, so please let me know if you see any issues.

Version 1.06 Changes:
    - Fix: Return the release year when a master is not available.
    - Change: omit outputing the Disc # field when the value is 0.  Although MC doesn't tightly
      differentiate between 0 and empty, a 0 value appears in file tags and is seen by other apps.

[MrC]

I found an interesting case yesterday while creating version 1.06.  The album 2112 by Rush has a single track on side 1 of an LP, or is indexed as a single track 1 on a CD, yet is listed in Discogs as 7 sections of track 1:

1-I       Overture    4:33
1-II       The Temples Of Syrinx    2:12
1-III       Discovery    3:29
1-IV       Presentation    3:42
1-V       Oracle: The Dream    2:00
1-VI       Soliloquy    2:21
1-VII    Grand Finale    2:14

I suppose I need to merge such entries into a single track 1.  Maybe it should be like this:

    Track #:  1
    Name:  I-Overture (4:33); II-The Temples Of Syrinx (2:12); III-Discovery (3:29); IV-Presentation (3:42); V-Oracle: The Dream (2:00); VI-Soliloquy (2:21); VII-Grand Finale (2:14)

The durations could instead be starting times of each section so you know where that section begins.

Any thoughts?

[InflatableMouse]

I found an interesting case yesterday while creating version 1.06.  The album 2112 by Rush has a single track on side 1 of an LP, or is indexed as a single track 1 on a CD, yet is listed in Discogs as 7 sections of track 1:

1-I       Overture    4:33
1-II       The Temples Of Syrinx    2:12
1-III       Discovery    3:29
1-IV       Presentation    3:42
1-V       Oracle: The Dream    2:00
1-VI       Soliloquy    2:21
1-VII    Grand Finale    2:14

I suppose I need to merge such entries into a single track 1.  Maybe it should be like this:

    Track #:  1
    Name:  I-Overture (4:33); II-The Temples Of Syrinx (2:12); III-Discovery (3:29); IV-Presentation (3:42); V-Oracle: The Dream (2:00); VI-Soliloquy (2:21); VII-Grand Finale (2:14)

The durations could instead be starting times of each section so you know where that section begins.

Any thoughts?

How about this?

I. Overture (4:33); II. The Temples Of Syrinx (2:12); III. Discovery (3:29); IV. Presentation (3:42); V. Oracle: The Dream (2:00); VI. Soliloquy (2:21); VII. Grand Finale (2:14)

or (as its tagged in my library):

I. Overture (4:33) / II. The Temples Of Syrinx (2:12) / III. Discovery (3:29) / IV. Presentation (3:42) / V. Oracle: The Dream (2:00) / VI. Soliloquy (2:21) / VII. Grand Finale (2:14)

[theoctavist]

I've been looking at this, and have a question.

What is the advantage of this command vs having said metadata pulled/written by xyz tag app? a couple of them pull from discogs/musicbrain/amazon by default.


is the advantage the fact that you are keeping the files within JRiver instead of farming tasks out?

still somewhat new with JRiver utilities, so questions are plentiful.

[MrC]

There are plenty of apps that will pull from external sources, but they will operate in their own way, pull data according to their own rules and specs, but not operate on MC fields directly.  I wanted to create some scripts that could pull data from discogs, amg, etc., and have them populate MC fields in the Library (either directly via MCWS or via MPL import) rather than update external file tags and have MC read those tags.

A couple of features were important to me and other users:

   1. user-defined MC field names
   2. credits mappings
   3. selective field assignment (via inclusion or exclusion rules)
   4. ability to populate MC metadata pre-rip (fills metadata values for the CD entry in the CD database, which carries forward to ripped tracks)

I'm not sure if this addresses what you are asking about, but maybe its a start.

[theoctavist]

fantastic info. thank you.  So it does have many advantages over mp3 tag. Gonna give it a whirl.

thanks again.

[lepa]

Various Artists issue. Artist field is populated with "Various" instead of track artists
http://www.discogs.com/Various-Atlantic-Rhythm-And-Blues-1947-1974/release/3868258

[MrC]

Various Artists issue. Artist field is populated with "Various" instead of track artists
http://www.discogs.com/Various-Atlantic-Rhythm-And-Blues-1947-1974/release/3868258

Thanks for reporting.

I've fixed this, but would like some feedback before releasing.

I've added a new key/field for 'albumartist' => Album Artist.  This is useful for cases where a predominant album artist should be used, such as Mark Isham for the sound track to Body Shots, where only track 1 is by another artist (Moby):

   http://www.discogs.com/Mark-Isham-Body-Shots-Music-From-The-Motion-Picture/release/2137557

In this case, both track artist and album artist will be output.

However, for some albums like the one you reference, since MC already does Album Artist (auto) detection, there's really little reason to output "Various" for an Album Artist field.  But this could be handled in two ways:

   1) I leave it to the user to add albumartist as an ignore field on a case-by-case basis, or
   2) I detect when the album artist is some form of the term "various" and suppress album artist in this case so that MC's Album Artist (auto) does the right thing.

[MrC]

I've posted version 1.07, as the Artist/Album artist issue is worth making available.  I'll deal with handling the sub-tracks issue mentioned above later (it is non-trivial, as basically the data on discogs is bad, so I have to unify it in an external data structure).

Version 1.07 Changes:
    - Fix: module Bit::Vector was not being imported, causing the script to abort when using
      the --range option.
    - New: key 'albumartist' mapped by default to Album Artist is available.  When it is some form
      of the term "various", it is suppressed (the assumption being that track artists exist), so
      that MC's album artist (auto) logic will apply.
    - Fix: album artist was being used in all cases instead of track artists, which was problematic
      for mixed-artist or compilation albums.  See also the description for the new key 'albumartist'
      above.

[lepa]

  2) I detect when the album artist is some form of the term "various" and suppress album artist in this case so that MC's Album Artist (auto) does the right thing.

I'm in favour of this one. This is how I've done it manually. So it is multiple artists album if there is no "main" artist

...and thanks for the fix above

[MrC]

I've made a fix for the multi-part track issue I reported in Reply #66, and followed InflatableMouse's suggestion as implemented in his library (using " / " as the sub-track separator).

Before I release the update, because the fix feels very special-cased, I'm wondering if anyone knows of other similar Discogs entries.  That is, releases where some track is split into sub-tracks, but on the CD that track is indexed as a single track (i.e. ripping produces a single track).

[lepa]

Not sure if this one fits the case. (I only have LP version) In my rip I have single Devil's Triangle track.
http://www.discogs.com/King-Crimson-In-The-Wake-Of-Poseidon/release/3872923
http://www.discogs.com/King-Crimson-In-The-Wake-Of-Poseidon/release/3236598

[InflatableMouse]

That is, releases where some track is split into sub-tracks, but on the CD that track is indexed as a single track (i.e. ripping produces a single track).

No time indices unfortunately.

Track 4: http://www.discogs.com/Dream-Theater-A-Change-Of-Seasons/release/387427

Track 11: http://www.discogs.com/Dream-Theater-Falling-Into-Infinity/release/387421
Lame thing is its mentioned in the notes. Mine is tagged as:
Trial Of Tears [I - It's Raining / II - Deep In Heaven / III - The Wasteland]

Track 2, disc 2: http://www.discogs.com/Dream-Theater-Black-Clouds-Silver-Linings/release/2512944

[MrC]

No time indices unfortunately.

Track 4: http://www.discogs.com/Dream-Theater-A-Change-Of-Seasons/release/387427

Track 11: http://www.discogs.com/Dream-Theater-Falling-Into-Infinity/release/387421
Lame thing is its mentioned in the notes. Mine is tagged as:
Trial Of Tears [I - It's Raining / II - Deep In Heaven / III - The Wasteland]

Track 2, disc 2: http://www.discogs.com/Dream-Theater-Black-Clouds-Silver-Linings/release/2512944

Thanks, but these are not quite what I meant.  Each of these is a single row in Discogs, unlike the Rush 2112 entries which split a single indexed track into multiple rows.

Technical: each row in the Discogs page reflects an entry in a single tracklist array, and I use the listed disc #/album #/track # on discogs (stored as a position value) to figure out which of your tracks matches one from that array.  And as implemented, the position maps to a single location in the array, and its a two way relationship.  But the (incorrect) splitting of a single track into multiple rows breaks that implementation, and so I massage the array, coalescing the sub-tracks back into a single entry so that the mapping is restored.  At least one discogs author of a 2112 release used a proper sub-tracks split within a single track, but most have not.

[InflatableMouse]

Ah right. I didn't actually look at 2112 on Discogs 

How about this one?

http://www.discogs.com/Romeros-The-Romeros-Play-Vivaldi/release/2610775

[MrC]

Not sure if this one fits the case. (I only have LP version) In my rip I have single Devil's Triangle track.
http://www.discogs.com/King-Crimson-In-The-Wake-Of-Poseidon/release/3872923
http://www.discogs.com/King-Crimson-In-The-Wake-Of-Poseidon/release/3236598

Ok, so it appears for the CD release that the 7A-7C should be a single entry, which I'll combine.  This is yet another pattern case I'll have to implement (A-Z or a-z being used as the sub-track identifier/index).  Shall I do the same for the LP release (B3a-B3d)?  It seems reasonable given that you have only a single track.  But with LPs, since you can't "rip" them based on pre-defined indexes, I suppose you could arbitrarily split a song into any number of files.  This almost begs an option to defeat the feature, but that's more work that just adding the option.

[MrC]

Ah right. I didn't actually look at 2112 on Discogs  

How about this one?

http://www.discogs.com/Romeros-The-Romeros-Play-Vivaldi/release/2610775

This one is OK.

Vinyl uses a <side letter><track number> pattern and I expect these.  It was patterns like <side letter>-<sub-track> or <side letter><track number><sub-track>, such as A-II that or B3c that are my only clues that rows should be coalesced.

For CD releases, tracks should be in the format of <track #> or <disc #>-<track #> and I use incorrect entries such as 1-IV as a clue.

Its all a bunch of heuristics to deal with incorrectly entered position values.

[MrC]

I've posted version 1.08, which deals with the few cases of split-track entries we've been discussing.  Please test out some of the URLs above to see how they work for you.  If you find others, and they don't work, post the URL and I'll make corrections if possible.

Be sure to install the new required module on Windows (see below).

Version 1.08 Changes.
    - New: combine multi-part pseudo tracks into a single track entry.  The individual titles
      and durations are combined into single long track title for the track.  For more info,
      see: http://yabb.jriver.com/interact/index.php?topic=87032.msg603884#msg603884 .
      This fix requires an additional module.  On windows, in a command shell, type:

        ppm install Roman

      and hit Enter to install the module.

[theoctavist]

I've posted version 1.08, which deals with the few cases of split-track entries we've been discussing.  Please test out some of the URLs above to see how they work for you.  If you find others, and they don't work, post the URL and I'll make corrections if possible.

Be sure to install the new required module on Windows (see below).

Version 1.08 Changes.
    - New: combine multi-part pseudo tracks into a single track entry.  The individual titles
      and durations are combined into single long track title for the track.  For more info,
      see: http://yabb.jriver.com/interact/index.php?topic=87032.msg603884#msg603884 .
      This fix requires an additional module.  On windows, in a command shell, type:

        ppm install Roman

      and hit Enter to install the module.

having some issues.  this does wonderfully well on single disc albums, but it never fails that whenever multiple discs are involved, in spite of the track order in MC being lined up exactly as it is on a 2 x cd entry on discogs, the titles, numbers get all jacked up. any ideas?

[MrC]

Do you have a Discogs URL for me to test?

[theoctavist]

Do you have a Discogs URL for me to test?

yessir!

http://www.discogs.com/Wilco-Kicking-Television-Live-In-Chicago/release/677050

[MrC]

It works fine here.  Perhaps you did not supply the -s sequence option, which uses your track order irrespective of Disc # and Track # in your metadata.  Without it, discogs.p will use your disc #/track # pairing to determine which entry of yours aligns with which entry in the discogs listing.  I'm suspecting you don't have the Disc # field populated.  So use -s.

[theoctavist]

perfect! thank you.  sorry for the unnecessary Q!

[MrC]

@Nathan,

Edit: pre-release removed.

Here's a pre-release which includes the changes made to amg.pl earlier, as well as a new key 'playbackrange', which by default will set the Playback Range field.  I've chosen to use milliseconds so that you can adjust precisely if necessary without having to convert.  If you'd prefer HH:MM:SS, let me know.   By default, the config file disables this key (see: Options: -e playbackrange), since most users probably don't want this set.  Just comment out the option, or specifically include it with -i playbackrnage (place this option *after* the -c config file option, since later options override earlier ones).  See the Changes list for the list of recent changes.

[jmone]

MrC - Works really well!...  but a couple of things (one album test)
- HH:MM:SS:xxx is what MC (LAV) shows when playing the chapters and it is human readable unlike milliseconds (see red box in the attached pic).
- Looks like there is a small unaccounted for gap between the song length from Discogs and the chapter start points on the BD as the further you get into the playlist you start to hear more and more of the end of the last song.  Unfortunately these gaps between the songs don't seem to be exactly the same, though on "Average" gap is 740ms (ranged from 583 to 843 on the first 7 tracks of this album). 

I don't think the Playback Range needs to be millisecond accurate as the gaps between songs are pretty wide but an optional offset value to add at the each of each song makes sense as by the end of the album it is way off (by seconds). 

Does that make sense?

I take it there is no way to read this chapter info from LAV at this point?

Thanks
Nathan

[MrC]

Here's an updated pre-release that includes the features you asked for.  See the Changes file.

Edit: pre-release removed.

Example usage fragment:

    ...  --filekey --rid 5397834 -i name,playbackrange,duration --trackgap .75

Add a new field "Duration (ext)" and you'll get the duration values populated (unless you've excluded it, or if you're using includes and you've include the 'duration' keyword as shown above).

By the way, if MediaInfo can read the chapter start/stop values, I already have a pscriptor scriptlet that uses it, and another one that sets playback range.  It would be easy enough to modify it to instead pull these values.

[jmone]

Almost there I think, two issues:
- I get an error saying "Value ".75" invalid for option trackgap (real number expected)" though it runs fine with a value like "1"
- The playback range calculation is out by 60minutes (see pic) after the 1 hour mark

MediaInfo does not present the chapter start values and I think the above is a great alternative till JR have the time to just create the particles by chapters (and at which point it will be exactly accurate).

Thanks
Nathan

[jmone]

Actually, a "better" behaviour given the imprecise nature of the Track Gap would be to add it to the end time so the playback range is continuous but the start time falls in the correct place but it is not cutting off any content on either side of it.

Hard to explain, so eg from this ablum we have the following time and playback range with say a "1sec" trackgap

Track 1 = 4:33 --> 00:00:00 - 00:04:33
Track 2 = 2:25 --> 00:04:34 - 00:06:59

It would be better if the "trackgap" is actually added to the track length, so the playlist would like

Track 1 = 4:33 --> 00:00:00 - 00:04:34
Track 2 = 2:25 --> 00:04:34 - 00:06:59

Thanks
Nathan

[MrC]

Sorry, rookie mistakes.  I int'd when I should have mod'd.

I don't have any issues with using .75.    I'm using:

   ... --rid 5397834 -s --trackgap .75

I've updated the calculation to tack the gap to the end of playback, which caries to the start of the next item.  That's how I originally had it, but changed my mind for some reason.

Here's the update.

[jmone]

Mmmm rest looks perfect but I keep getting the error on .75

Code: [Select]

C:\Users\Nathan\Desktop\discogs>perl discogs.pl -c discogs-config.txt -i name,playbackrange --mediatype Video --filekey --trackgap .75

*** Value ".75" invalid for option trackgap (real number expected)

[MrC]

Ah, I see it now on Windows.  It is caused by a difference in behavior on Win vs. Mac of a standard module I'm using.  The Win behavior is wrong.  I've re-uploaded the pre-release above with a fix.

A workaround would be to add a leading 0:

   --trackgap 0.75

but with the update above that is not necessary.

[jmone]

Yup - leading 0 works!  I've got to go but will test more later today

That's how I originally had it, but changed my mind for some reason.

It is probably because we are calling it trackgap but what we are trying to do is hit the "middle" of the track gap not actually create one.

[MrC]

I'm open to better names.

[MrC]

I've merged the discussion about obtaining particle playback ranges to pscriptor, since it will involve a new pscriptor scriptlet to call MediaInfo (or other).

   http://yabb.jriver.com/interact/index.php?topic=85990.msg613636#msg613636

[lepa]

Is this script still working or did discogs change something in the API?